Good afternoon guys, hurry. How's everybody doing? I hope Still have some energy left for you know things days coming to an end Before I start a quick just show of hands. How many guys have her know what quantum does? Okay, how many guys have played with quantum? Okay, not so much Yeah, because I was the quads title was quantum on quantum. So I want to make sure you know If how much people understand how what quantum does obviously the user story We're gonna go over how we use quantum in our internal production environments and how we run You know how network virtualization Simplifies networking so much that you can actually run You know another layer of abstraction on top of it like kind of like inception for networking if you will so I mean it introduced myself. I'm so McBear as a founding member of the quantum project I worked for a nice era till till about now Now at VMware we we are part of the network and security business unit We were actively involved with the open stack community We're gonna go to our user story of how we use open stack internally and what how we what are the cost benefits and agility? benefits we have Achieve doing so Excuse me So, yeah, follow me feel free to follow me on Twitter. I post about being a quantum how things are changing how things are evolving interesting user stories and and Let's get started. So This we had quite a few user stories today a lot of people don't know dove down to the technical detail the network Architecture or you know the high-level open stack deployment. I'm thinking a little slightly slightly different approach to it I'm kind of looking at what are the benefits mostly we achieved and We'll get a little into how we did it and you know, obviously can ask me questions On details of any of the ass any of the aspects. I'm going to hold off till then for Q&A so getting Started let's see. I'm gonna make sure I know what the time is We So like like all of you guys we were Nice show this pretty small company. We we create scale. We grew really rapidly Everything was physical or I mean virtual, but we're just virtualization no cloud kind of environment and that was definitely very rigid it it was not because You know developers everybody said I'll give me cloud. It's just that it was out of necessity we wanted to move fast and if you're stuck in the physical world it was difficult to move fast and That's what drove, you know was the main negus impetus to guess trying to figure out how we use open stack internally You know to enable us to actually accelerate What for what we do so our main use case was first You have a bunch of networking developers, you know, it's probably the best in the world So that that's a good thing But the problem is that you don't want them to You know put them on your production network we still run a network and If then they're experimenting we're building next-generation networking technology So we have a very different set of challenges than a traditional enterprise does because you know They can actually take your network down because we are doing things which nobody probably does So how do we actually isolate? Like it's essentially what we do for work for servers to isolate them. How do you do that for network? We have a product which does that so it's like how can we use it to actually self-enable us ourselves to move faster? We're a networking developer if you don't virtualize the network, you know, we actually will hurt ourselves So it was like a real necessity like this is going to open set clouds going to network virtualization Was the only way kind of out for us unless we want to take the rest scale, you know one day Some super smart crazy Networking developer is going to take the whole thing down just because he was trying to play with you know How we can how we can change how we do? multicast handling and In our virtualization layer or something next use case was We nice here. We're a very, you know fully software company where we make Distributed systems to handle network virtualization We deliver software really fast. We believe in agile methodology every four weeks for enterprise software That's you know, not unheard of and a big ball into achieving that kind of agility that kind of speed is continuous integration build continuous integration and and at low cost we were a small Scrappy startup. We didn't have couldn't dedicate hundreds of physical servers to do continuous build and integration testing So we wanted to have the agility or the scale of big the big guys You know, maybe we you know, I can how can we use our infrastructure of developer work work in environments, maybe at night to do continuous integration when nobody uses using it the only real Option is you know, you can't do anything unless you use cloud So like now we have a shared pool of capacity Developers so whoever is using in the morning the workloads actually die down in the evening You can use it for a different set of tasks You know for the throughout the whole night the same you're using a resource requirements by by a huge factor So that you know, so we have this dedicated build environment runs at that capacity at all the time And then when there's cloud capacity we burst into it Because we are using a virtualized network. There is you know, we can it seems as the same network and you just grab compute capacity They have L2 or L3 reach ability most of times we actually provide L2 reach ability and while out there you go You have more capacity when you need it and that accelerates our ability to deliver what we do best deliver software 30 use cases that we're a whole bunch of application. This is a complex You know exchange kind of application, but we have much bunch of applications like this our actually network virtualization solution is It's pretty complex and to deploy once we deploy it It's easy for users for open stack users or any of the cloud management platform users to virtualize the network But it is not easy to deploy it internally so The this use case was driven by you know accelerating.  How do you develop really complex applications fast? It used to take us? I'm going to go how long it used to take us but you used to take us few days to how do you bring up to the cloud and deploy it in in seconds we'd you know We did that by Essentially once you virtualize it we could author these labs or these applications and the topologies What what are the different elements which go different networks and kind of have this if you will manifest? Which goes with every one of them and then you know you click a button With within a minute you get the entire infrastructure deployed and we do do a whole lot of that because Every time it's a sales guy or overseas have to do a demo They need to do it and before you stick them at least a week to rig the physical hardware to do it and That was definitely inhibitor to our products at adoption and how fast we can actually demonstrate the value So that was this was another out of necessity requirement like how do we make this complex enterprise? applications work fast and and so that was our final use case and I'm and other few things I wanted to go over was Since we went down this path of bringing our own open stack cloud What are the and with network virtualizing network with quantum? Why did we do it and just give a contrasting? You know how it was before and what what were benefits we got out of it then we can Have any questions later on and any of this how we if you have questions on why we think we had these problems are How did we actually accelerate this? numbers I'm talking to you about so Before quantum I was talking about my first use case remember so Every developer pretty much we were a small company So we the only way we could actually make sure they don't bring down a corporate network was that every developer had had their own private VLAN and it nothing goes outside that boundary Anything else, you know, and that's also still risky. You know, these are these are pretty good networking telephones talking about We are networking guys are pretty nervous, but But even even with that isolation was not fast enough because people are moving between projects or they were to collaborate You know two guys two guys are working on a different feature. They had to you know, and you have to change their VLAN so they can actually They're collaborating when they're coding how do the test that if they're not in the same test environment, right? So every time you make changes it takes at least couple of days even for a fast Startup like us to actually get the networking guys involved that would change and give the right guys access to the correct VLAN everybody on the same page and That was a really big win for us to actually Me virtualize the network Click off a button you get what you want You have this notion of projects you can just share with multiple people you can add delete depending on you know Who's working on it? And you know, I say 20 seconds. It's really not 20 seconds It's like it's under a second API call 20 seconds to actually you know to drop drop down the UI select I want this network. This is these are the guys like I want to give access to this project There you go. So we got out of it, you know, nobody takes on the corporate network anymore. So So that was that was really big when it Helped us go the go down the path of this continuous integration fast development modules fast deployment second scenario I was going to talk about was that Like I was talking about our build and QA and continuous integration use cases Are as we do grew the product it became more complex more features that means means The oldest means one thing means, you know, QA is going to say oh, I need more resources to test it. I need more time Build stick longer And that that's how most companies actually slow down our most really large enterprise environments is just you go from, you know, TV development cycle to six weekends before you know six months and and everybody knows what happens after that and We from fundamentally we the company we structured we were all about agility Speed and flexibility. We're like we can't go down that path We can't have we have to fundamentally redesign the way we develop things the way we we have redesigned the way we don't do networking we have to redesign the way we function as a company and That that's how we we're like We can't scale by like incrementally adding more capacity or even renting capacity co-location facility none of them models work They're not cost prohibitive for the kind of scale we operate at we are you know our products Being used in really large customer environment really the world's largest telcos hosting providers Just was unfeasible. So what do we do? You know most networking guys. They don't give deck, you know Guaranteed bandwidth, you know if you need 10 gigs for application one day of the year you don't You know, you can't build you a lot of times you actually build the network to that capacity and that was not an option for us So we did what what is the next best thing we we try to? oversubscribe Or capacity and that and open stack or the cloud environment really led us to that and we actually started now Not only over subscribing, but efficiently sharing this as a single fungible pool of resources No A lot of everybody has their Macs or whatever where you write code But you need to deploy to some machine to test it to you know build build a few networks and run unit tests and such So developers come in, you know, they have their code wherever it's in the repo They pull it out they can launch up a VM to actually push down the unit tests to run the unit test Do functional validation And you know a lot of times most of people don't really need that VM anymore If if you have really good automation and infrastructure to do that and then so when they go home We there is no need to actually have that VM anymore. So the cultural change People have get used to it that everything has to be automated from ground up from day one Nothing can be manual can be that we can't do without automation and it's it's kind of a It's usually painful when you do when you introduce cultural change But it pays, you know, I guess many fold exponential dividends down the line because now everything is automated It gives you new I guess magnitudes of flexibility and return on your initial investment of that you did on automation So the developers we started trying to do encourage that any persistent data is showed on stored on volumes So, you know some kind of persistent storage by the VMs is End of the day they're done. We don't need them. You don't you release the resources So now all of the night if you see if we see our Monitoring graphs of our cloud, you know, it goes up and then it goes down and that we're like, oh now we can actually Multiply x that that capacity and I'll start using it for a different function And that's how we use it to accelerate our build and continuous integration by making sure our Compute capacity is always at like maximum utilization for different use cases and then we can prioritize who gets how much quota To make sure that we are always utilizing it the highest utilization. Usually can be capacity is really cheap. It's about most people have challenges is because it's really difficult to deploy to You know in a fast flexible way to use it to harness that capacity so that's what our open stack deployment kind of gave us and you know There was a result that we were able to continue to accelerate and innovate at the pace we were as a small company But having become a little larger with a lot more features a lot more developer We kept on moving at that that velocity that that business velocity is is kind of it's really priceless, right?  I mean so that was a fundamental differentiator or motivator for us to do this Next it was a my third use case. I was talking to you guys about those I was telling about you know every time we had we had To do a proof of concept our network virtualization solution We know it had these really humongous three of these boxes the particular set of you know administrative Networking configuration and just do some you know multi-destination traffic offload boxes Some device some other devices we interface with the external world. Somebody has to go install isos on them You know you have to get if it's a customer site or something Even worse you have to get their networking teams involved. They're like oh Who needs which firewall for these boxes on this network and it needs another another second network or you get switches and Yeah, it was just this nightmare. I mean I said three to five days But those are you know for really good customers who are all around here It took them were really smart and brilliant and have a very efficient networking and operations team it still took at least three to five days to get it up and running and While it was great, you know, we were when we were small We had a handful of people once we started scaling the organization There was no way we could we could keep up with that model like three to five days was just too expensive to dedicate and there has to be somebody to help you all that time right because Because most of time you're not doing anything fun or we know your sales engineers said they're not really Installing or demoing the product there and they're waiting for infrastructure to keep up with you know the speed people Want to proceed So now I'm gonna do a demo is we have the plus is a complex application later on It takes up about roughly about a minute sometimes less So that was it was not about going from three to five days to a minute I mean even though that that's a great achievement and there was a great accelerator now But it was about simplifying all of that now that we have codified that into a schema or Manifest I was like I was saying of this lab deployment topology needs these many VMs three to four different networks Firewall policies here and that's what I need and make it happen go cloud make it happen for me So that's what a cloud environment does you push a button you you get that right so and About you wait a couple a couple of more minutes. It's all up and running and That's that's that's humongous right it accelerates your time to revenue Many many folks like you know your sales engineering or human talent or human capital You have it's the most probably precious asset or in your company. So that's what we are actually getting out of it You know, it's not about money or saving on your capex or and you know All your op-ex or we are deacons infrastructure But the business value get a getting out of it actually going from you know five days to two minutes that's like I don't know exponential and the factor of Productivity increase you're gonna get out of your workforce. I mean and probably a good thing because most people when they do more They were going to feel more successful. They're gonna be able to do more. They're gonna be happy as a organization of the company so That was the wrong one This is supposed to be basically we increase your time to time to revenue, you know by exponentially many fold so Oh, this is oh, I went back. Okay. Yeah, we reduce your time to revenue by like by humongous Factor like Basiliant pretty much if you do the math of you know seven day or five days to do a single minute So At a high level that's that's why I see our chose open stack That's why we chose for network virtualization and at the end of it That's why he chose quantum with using network virtualization to enable a cloud environment That really helps us achieve our mission to our customers to our partners and be able to innovate at the rate We have innovated and continue doing so and show those show the world why we can do it and we'll continue doing so So the high-level, you know, this be many people who have been working with quantum Probably familiar with it. I just a high-level picture.  We're gonna upgrade to fold some very soon But right now we're using sx if you fire stuff a call to the cloud controller and the cloud controller Schedule gives it hands-over schedulers a scheduler puts on the message bus is like need this much capacity this flavor VM go get it One of the compute workers who has a capacity picks it up where would or who does this time for The compute worker actually picks up that request creates the virtual machine image and it has a networking Specs with it which are the networks in need to create three networks three then it creates actually three nicks for the VMs and In in sx we had some a notion called quantum manager. That's how we integrated it's changed with Folsom happy to discuss if later on if anybody wants to know how it's changed but So it essentially creates those next then makes calls to quantum using, you know The quantum or API saying I need this neck to be plugged into this network three next these three different networks and quantum go make it happen You can make it happen using, you know the open source open v-switch plug And we use And our product because we eat our own dark food and we had to make sure we keep continuing doing that so we use MVP the network virtualization platform to actually create a virtualized overlay network for every one of them and make sure that these nicks are plugged in and And you know then nova nova gets a htb to 200 request Succeeded command that means it's all it's good know what parts of the VM and no one really doesn't know anything The VM is automatically on the network. It sees IPs. It sees everybody all its peers So even this is virtualized networks from a nova perspective from an open-stat flow perspective nothing changes You know, it's the same thing you do with the open stack just that it's on a Virtualized network, so you don't have to get anybody involved. It doesn't use You know, it scales your physical network better. It doesn't expose all your max and In this in your cloud environment to the physical network So you build your physical network once and you can you can you know get You can scale it really better You can make you can have a lot more workloads Working on the same thing like cloud environments dynamic agile workloads where we are doing this every day I'll go with go with some numbers later on so We have right now is looking up cloud We have about two fifteen hundred or two thousand VMs running, but it's not about the these are not VMs We just spun up and we ran it We actually bring it up and down up and down every day these networks like you know Thousands of networks up and down and up and down every day imagine I mean your traditional IT infrastructure if you're a networking guy you have to be able to do that to actually Get the business velocity that you want you know to be able to For your software development for your you know customer side proof of concepts It just isn't fundamentally possible like that's that's like a bazillion like I was saying time correctivity increase It just cannot happen so And and then you know we get a VM Get a network So we make a few of those calls we have our typical Product is like takes about 13 VMs or 12 VMs four or five four networks You know these calls about take the total of our it's about a minute maybe two if if there is a lot of load and There you go and everything is done As far as details When a request comes in the quantum Frontend API it gets gets delegated to the plug-in you're using in a crisis NVV plug-in It goes to the NVV cluster the NVV clusters You know is a scale out just to be a system which actually manages all of the switching elements inside all of the Compute hypervisors we have we have a mixed environment actually we use KVM we use Zen because we work across everything So we our cloud actually has you know we try to support as many of them as possible in the single environment and And then from it like I already talked about the user workflow how things happen nobody sees a change under in the covers what's happening is the Network which led the controller is programming this virtual switches at every layer Just to tell it how to actually use the net you know Get a tunnel between where the whatever Whatever the packet needs to go so that's why the packets never go on a physical network They get encapsulated and sent it to the right destination Automagically somehow I'm happy to discuss more about that, but this is that's beyond the scope of this this presentation so So Once we had this I wanted to share is how you know the kind of adoption It's it's not that we are using a dev test some people say oh they're using dev test They're using production we use we are running essentially, you know if we're in we're a company We're enabling clouds are really large enterprise public clouds. We have to be you know We bet we're gonna better run our business on it So we kind of run across the across all sectors customer support training Dev and QA sales I see this is like real data. I got about a week ago We're just curious to work out the distribution we had so as you can see, you know It's essentially every part of a business runs and actually went to our top three, you know productivity boosts we got out of this effort actually doing We're running an open-sac cloud or running a cloud with using network virtualization, but it could cause each of these Verticals we had similar just unimaginable I guess gaining value and how much more proactive we have been so This is number of instances CPU utilization memory, but it's about the same you can say, you know the best most of the users are on Dev and QA and It used to be a Dev and QA and sales in SE, but we started kind of splitting You know this sales guys not kind of could do things faster. So this actually talks about How many hours people have spent also Kind of takes out into account So that's why the training and labs started taking more and more portions because that's where people spend time Before all of that was convergent was one single pie so So across all all aspects of the outcome company we have had Really significant productivity boost just because we could have get the agility we have never been able to get I would you know people with a lot of people who are talking about Does this thing work this table is open stack ready? So I just got a graph out of you know our adoption curve You know, it's it's in April weeks We launched this cloud because that's when a company started growing and we had to continue We had this immediate challenge and how do you do it? And this was the only way to do it was the fastest the path of least resistance fastest way to actually be able to solve Those problems and have that game that kind of agility. So as you can see we have a pretty steep Growth curve. It's pretty much mimics the radar company was growing I put a circle over there because that looks like you know, they had a failure. It was not really a failure That's in August end of August. That's when I see I was acquired by VMware So the IPs got the monitoring system got re IP'd so the This monitoring system which actually keeps track of it We use ganglia and it just lost connectivity. So it thought the world ended but It isn't what it looks like so that's But other than that it's been it's and the other thing we have seen as a step function That's because we kind of have quotas for developer It's it's it's been it's been kind of like a like a drug If you people because the more we give the more more the consumer and it just doesn't come and Another way to look at it out the way I look at it is It must it actually gives them such productivity boost that there's a lot of them Just can't go back to the old way of doing things like I cannot be that unproductive now that I've got in use of this fast Agile productive way of doing I'm delivering better. I'm performing better Every every person actually can do more with a lot less and only do more with a lot less But do things faster and do it himself without getting anybody involved And in our we are since we are we are really focused on networking We never get any of the IT network infrastructure everything is self-service and our network Infrastructure teams don't really care about it because it's contained. It's where it's virtualized. You can't do any damage You know you can you can shoot yourself on a foot, but you know be my guest do it yourself you pay the price Then this step function I was saying is because of quotas we have put in because of that at reason So as things things and I assume that we're gonna have some more hyperbys is a coat I will go up Other things to notice over here. This is the load. We are tracking The reason we are tracking loads not by number of VMs is because we I was like I was telling you earlier We try to fundamentally change the way we double software and the way we do business So it's we don't really you know Use the cloud but using the old way like spin up a VM and leave it on instead of my Machine under my desk now a VM in the cloud I mean that does give you a lot of benefits a lot of productivity boost but not Not in the way if you actually fundamentally change you are how you're using those VMs You're using as a femoral pieces out in there. I'll use it on demand I have everything is automated against you know You can use chef or you can use scripts or something else to deploy my application and get it going in a couple minutes Then everything is ephemeral so these are like load which we experience every day and at different times I've had to go a different graph. It will actually go down. It's it's it doesn't it's in a constant load So that's another big Benefit we Cain from going using the cloud is like the cultural change. That's actually the most invaluable Benefit of game. I mean, it's great clouds great. You get capex efficiency opex efficiency You can do things you couldn't do before but the cultural change organizational change That's usually the biggest barrier and once you actually successful implemented you have got that change You have a lot more agile organization. You can do a lot more things or You know invest resources and do it faster for your business priorities that you couldn't do before so So I don't think let's see how much time I have a little time so I'm gonna go and Talk about our demo topology what I'm going to deploy the lab house topology. I was talking about is essentially these We have Well, essentially I can go over what what it is, but it's a bunch of VMs need then each four different networks privates I isolated networks different security policies they can't talk to each other and That's because we do network virtualization some of these components are over the management network for management traffic and You know data network is essentially You know a physical fabric where you used to do overlays on top and you know, this is a demo topology You know, you know a sales guy goes and that is to show what's going on That's so I'm gonna show and a second sales guy comes in for a different customer He shows up another tenant so we can create a multiple of these and do it fast under within a minute or so So I thought for the do let's try to do the demo It's always a little challenging And doing one of these so So what I'm So here's our cloud UI. This is essentially a front end to Nova We have we could use horizon. We just had this use case of authoring labs There's nothing like that and we're moving fast So we just put an UI up against the Nova APIs and not doing anything fancy just using the Nova API just different UI So we have here is this thing called labs which are essentially You know a collection of manifest a bunch of VMs and networks and powerful policies How I want this environment to look like look like so I have this thing called open stack quantum training lab You can see the requirement needs like you know 40 meg gigs of RAM 12 CPUs seven machines Seven servers, so I'm gonna go ahead and oh So here I can monitor the status using This is because we are using the MVP plug-in for quantum and see there it is you know, ma'am It's an I'm the tenant. I have no switches. No ports I'm gonna go ahead and Deploy this lab And it probably take me a few minutes to Okay, so you see it's just starting to build out all the VMs It's an ad VM to show the external connectivity. There's the network controller. This is a this is a quantum demo lab I'm deploying actually We were actually gonna use this if you guys have time tomorrow morning to enhance on lab on using our cloud to Give it experience with how to deploy quantum and you know install it and get familiar with the commands and such So I'm deploying the same lab What we're gonna do for all of a whole bunch of as many of you as we can tomorrow to get experience with it so it's Doing it as we have seen in the networking side. We can go in debug and see What what has happened we can see that there are a whole bunch of ports which are these and Logical switches which are essentially our networks which have come up with this lab needed and They're live that it's gonna take a few minutes to spawn So while it's happening. This is happening in the background This is doing everything at traditional what we used to do in I was saying like five days, right? You rig up a server you give them this much capacity create the network and then there you go It's it's done creating the entire topology now the infrastructure is created essentially of these that complex app I was showing but The VMs are actually now installed, you know booting up and some of them are booting up from a remote volume and attaching them And there's scripts inside them to actually do that and that's what's going on in the background so I'll just go ahead and show you the network connectivity that all the network is in up and Show you that they're real VMs this little latency might take me a few minutes, but we might have to actually you guys might take a little more than a few minutes before they're actually all booted up fully and pingable and stuff, so I Will I guess I'm gonna start taking questions now you have and while this thing happens in the background and then Once it finishes I can do the ping test and such So if you have any question, please come on to the mic And yeah, we appreciate it. Could you talk a little bit more about the 10 lane is Maybe contrast it to open v-switch and gre and then maybe talk a little bit about the roadmap Are you gonna be extending to things like VXLan and nvg re? So darling, it's from an open-sac perspective. You don't never see a tunneling protocol You see I want a virtual network. You get a network I want these VMs on this network. You get it as far as what the nice US product supports. Yeah, it supports STD, it's an ITF draft. It supports it's gonna support VXLan. It supports gre and it can use any tunneling format It's just a low-level protocol detail of how you do virtualization But the real value is from an open stack from a user perspective The value remains the same like you're gonna get virtual networks and this is gonna work from day one Go ahead So it appears to me that you have packaged a bunch of VMs the network policies and the security policies together using some template I was just curious about how you created that. Is it a an open-source template? so So the template of this app I was showing the that's why so we created our own UI It's just an XML descriptor file saying that these are the components I need and based on that It makes a bunch of calls to Nova and quantum to get the network set up get the VM set up and plug them in just a Refinement if you would say on base open stack API's and because that was our use cases for in our pre-sales Kind of function. This is still booting up. So It's gonna be a few more minutes before actually Is that available While open source that template It's it's nothing really fancy. You all the API's are there you can Everywhere everybody's actually Free to take those API's and it's really easy to Cobble something together. We had some but a couple of guys who did it and did it in a free time over like three four days So are you doing? So said if you think there's any value and it would seem very specific to our use case I mean I see a lot of value in that are you doing firewall policies netting Whole lot of you're grouping everything together for the lab in that XML descriptor right pretty much what you need So this policies are actually There's one distinction to be made. They're just calls to quantum quantum extensions So we are not actually make calling firewalls. We're not creating firewalls or anybody doing not doing anything logic This is all front-end. So it's just making API calls So, you know anybody with you got a good Ruby on Rails developer and you give them the Nova and quantum API I don't think it would be really hard to we know turn it out of work Yeah, any more questions? Okay I'm trying to see if my other VMs are also booted up. It's going to take a few minutes But yeah, but I think it's going to take a few minutes to boot up You know, I'm running out of time probably one minute left So you guys are happy to come back to me at the VMware booth. I'm going to be there I can continue finishing up the demo and things and such Thanks very much You


Welcome. This is Melissa Armo. The stocks will show reviewing Netflix. Nice solid drop down in here on Netflix. I Called four trades in this last week on Thursday, and they fell felt value could have got out of them all actually on Friday You could have held them all until today, and they kept going Dream target on this really was 300. I think today was a good exit on this 30581 close enough Really really really super duper move on Netflix, and I do think Netflix is one of the stocks that actually still could be lower But again when you're taking a trade if it is a set parameter It's an option trade with a set time which the ones I called were up to the 26 You have to be aware of that and when you're up a decent amount of money 50% 100% or more in the for return investment trade you have to you have to make sure you exit It's never over to the fat lady sings you have to get out of trades with profit Okay, and when you're looking at options you have a time sequence, but I definitely think this chart is lower This was earnings last week. We did the day trade the puts. I mean this just worked really nicely So again good exit if you held this through today if you get out of this Friday That was profit to we'll look to see where we get this is a big big week this week And we'll see if Netflix is affected by the other earnings that come out this week It will be very interesting to see if it's affected in a way that it makes it drop more or if it rallies So be watching Netflix to find out the next golden gap class is July 27th and 28th email me I'm a list of the stocks wish comm if you'd like more information. Have a great day everyone


My name is Jerry Cooperstein. I'm the director of training at the Linux Foundation and also the maintainer and developer of the LF320 class, which is titled Linux Kernel Internals and Debugging. And today I'm going to give you a brief introduction into the use of kernel modules. So let's get started. The Linux kernel often uses modules, which are code which can be loaded on demand and unloaded when not needed anymore. Often modules are used for device drivers, but they can be used for many other purposes. For instance, different network protocols, different file systems that may be needed at various times. And so the code is only loaded when necessary. And basically almost every kernel facility, whether it's device driver or something else, can be developed so that it can be loaded as a module rather than built into the kernel that automatically starts every time the system begins. So let's take a look at how modules are written and how they're used in Linux. So here's a very trivial example of a kernel module. We have the code here. There's two basic functions, which are in virtually every kernel module. There's an initialization function, which gets called every time the module is loaded. In this example, it's called myinit. And you notice it's marked by underscore, underscore init as attribute. And then there is an exit function, which in this case is called myexit, which is right here, which is marked with the attribute underscore underscore exit that gets called every time you unload the module. So when you load the module with the insmod program, which we'll mention later, the initialization callback function is called and the exit function gets called when you unload it. The way the system knows that these are callbacks associated with loading and unloading is because we use the module init macro and the module exit macro to load them. So this is a totally complete module. All it does is say hello when it's loaded and say goodbye when it's unloaded. So it's really just the usual equivalent of a hello world program. There's two additional lines at the end of this. There's a module author and a module license macros are used. The module author license is just, the module author macro is just for documentation to give yourself credit. The license does matter though. Here we're using the GNU, the general public license version two. And that has some implications for how your module may be used later and what it has access to. Though in this session it really won't matter, but that is important. So now that I've written that trivial module, and it's presented in the solution set for the class so everybody has access to it and can use it for a template for doing more interesting things. How do I actually compile it? And then we'll talk about how we get it loaded. Compiling modules involves use of what's called the K build system in the kernel. It's a very somewhat idiosyncratic but easy to use set of scripts, et cetera, that are used to compile kernel code and modules in particular. For normal software packages, you're usually just told what headers you need, what libraries you have to hook up to, give an advice about optimization options and flags and then you go ahead and compile. You can't really compile the Linux kernel that way. It's become very important to compile in a way that respects the way the kernel is configured and uses the same options that were used when the kernel itself was compiled, et cetera. And in this section, we talk in detail about how to do this and at the same time, I won't go through the details here but we give you pretty precise prescriptions for how to do that. It's really not that hard.  And there's a script here which we make available to students called genmake which will do a lot of the work for you automatically so that given a directory which contains some source code for kernel files as well as application programs it'll identify which are the kernel modules and then write a make file for you so that when you want to compile the kernel stuff you can just say make and not have to do anything more complicated. So it makes it rather easy. Question often comes up is are there any advantages to having a device driver or some other facility such as a file system be written either as built into the kernel so that's always loaded when the kernel starts or have it be able to be loaded on demand as a module later. Generally speaking, we try to have everything as possible loaded as a module. There's no reason to load things before you need them and so it's better to load things on demand. Also, if you're a Linux distributor you don't know what hardware or exactly software people need so it makes sense to kind of compile everything as a module and then only load the pieces you need as you need them. There are no real disadvantages to having something loaded as a module rather than built in so for the most part we usually do things that way. However, in embedded situations where sometimes we want to keep things as small as possible have as fast a boot as possible sometimes people dispense with modules and just have them built in because their needs never change so there's really no reason to have this kind of optional dynamic loading and unloading so that's the sign decision you make with embedded type systems. Loading and unloading modules is done with the INS Mod for loading modules and RM Mod for unloading modules and in the text we talk in detail about the different options you can apply for these programs and we also talk about the Mod Pro program which is used for automatic loading of modules it knows where to find modules on your file system and load the appropriate module for instance when the device is found, et cetera. So we talk in detail about how to configure and use those programs too. We have a section here where we go in detail through the module structure. There's a structure called a module struct that's associated with every module that contains every bit of information the system knows about that module and the most important pieces there are exactly what symbols that module needs to use, what other modules or device drivers, et cetera might be calling some of the code that's in your module so it's who I refer to, who refers to me, et cetera and the kernel has to do very careful bookkeeping and all that to make sure we don't get some kind of bug where we load something and then it tries to call a function that doesn't exist. The next section talks about how the kernel keeps track of hues using modules and there's two ways modules can be used. They can be used by various applications or processes on the system and they can be used by other modules or device drives, et cetera that may be loaded after this module is loaded. It's very important to keep that count accurate because you cannot unload a module which is being used by somebody else that's sure to crash your system so we talk about how to keep track of that. In the early days when I first began working with Linux somebody writing a module had to take care of incrementing and decrementing usage counts manually which is an error prone process. Nowadays most of this is done automatically by the system and we talk about how to set up your modules so that this automatic reference counter can take place. And we also talk about the cases where we don't keep track of this for various reasons such as network drivers and why that makes sense to not have to try to maintain an accurate count of users. The next section has to do with module licensing whether you use an open source license or proprietary licenses, et cetera and what the technical implications are. We don't want to get into the legal aspects or instructors and not lawyers and they don't want to give legal advice and most companies have a lot of people working on this. So in this class we concentrate on the technical aspects what the advantages and disadvantages are of having various licenses. We also show you how to figure out what license various modules have on the system, et cetera in real time if you don't know that in advance. The last section I want to discuss on modules is about exporting symbols. As I said earlier, when you load a module it may require other modules to be loaded first or your module may need to be loaded before another module can be loaded. You may have functions, et cetera that are defined in your code that need to be loaded later higher on the stack. In order to do that you need to export the symbol and there's a number of macros, et cetera, export symbol that for a given function or a variable name make it available to any code that's loaded later. This is one essential difference between modules and built-in code that's always loaded when the kernel starts is that the kernel itself is one big monolithic program and you have access to virtually all symbols in the kernel from any code in the kernel as long as the code is not defined as static as a keyword. But modules have a more restricted API they can only directly access functions and variables which have been exported. So in this section we talk about how to export various symbols, how to restrict the use of exported symbols and some other variations such as export symbol for multiple CPUs, et cetera. We discuss all that here and it's pretty straightforward but you have to understand the implications. In the next section which is optional we don't discuss here we talk about how modules can resolve the symbols and find the hexadecimal addresses, et cetera and that's kind of a technical detail. Then finally, we have a number of different laboratory exercises that we do in class. All our sessions, almost all the sessions have multiple exercises. Many of them are C programs that need to be written. Both a kernel module perhaps and a testing program in user space and there's generally too many to do in real time in class but the idea is you pick the ones that interest you the most try to write them from scratch other ones you simply test the solutions and maybe make some enhancements to them. In this lab the first one is to write a module that iterates over every process in the system and prints out various information about it. This is essentially a variation of the PS command so you're writing one that can be run as a kernel module. The second lab is one that is a module you write which extracts certain information about your system such as what CPU it's on, what version of the operating system, et cetera. And the third one plays around with modules and exporting symbols. You write modules that export symbols and then you load other modules which try to get reference to them. And those are the three labs that are done in this session. I'd like to thank you for watching this brief excerpt from our LF320 Kernel Internals and Debugging class. We encourage you to go to our website and find out more details and look at the detailed outline for this class and we hope that you'll partake of training with the Linux Foundation soon. Thank you.


Good morning folks Steve Rhodes coming to you live from the shores of very sunny Delray Beach Florida this year 11 am update and we've got a sea of green out there you got all the U.S. indices trading to the upside dows up four tenths percent hundred thirty five points about one percent for the S&P or 40 points one and a half percent for the Nasdaq one hundred two twenty three the Russell's up seven tenths or twelve points one and seven tenths for the some eyes are up sixty two gold is up nineteen dollars silvers up eighteen eighty two pennies that's a three and a half percent move there about one percent for gold lights recruit up forty four cents natural gas down a nickel and a thirty a treasury up one point and nine ticks she's printed out a one nineteen twenty one let's go take look at our nine panel market update chart we begin up our left hand corner the ES mini what do we know about it well what we do know is at the bottom of its weekly profile bullish and structure by the way held and it held on Friday of last week forty three seventy seven so the S&P five hundred does not have a change in trend signal as far as where is price headed to I've got two different sets of profiles will look at these now during the regular show will look at the white background here we would say price is going to go target forty four forty seven to forty four sixty six now go forty four sixty six particularly the spot follow tunics over the last three trading sessions price is not been able to take out the prior highs but it has been able to take out the prior lows or least trade below them for a bit now we're trading below that that suggests to me that the spot follow tunics has changed its trend for the time being and is likely to go target that fifteen forty seven level that's a fifty day exponential moving average in the case the NQ you can see that also the last four trading session or three trading sessions price not made it to the prior lows and we're trading above yesterday's high in the NQ this suggests to Stevie that the NQ wants to go target that fifteen three fifty eight level but during the trader's edge so we need to go figure out where that oscillator and change line my guess is right now it's right where we're at so we're right up at a resistance level if we take a look at the US dollar index yesterday it formed a TD nine count top a close above one or three sixty two would negate that signal take a look at Goldilocks out here trading with inside a bullish structured profile do I have a bottoming pattern not really but price likely going to go target the top of that profile that's where the sellers reside at nineteen fifty three now the case of silver there are no sellers at this stage of the game and prices trading above its point six one eight retracement of its last leg lower so twenty four seventy eight would be its next price target area like we could early today was trading below seventy eight sixty if it did close close seventy eight sixty it would establish an A to B equal CD to the downside with regard to natural gas is trading below the bottom of its weekly profile could be telling us let's go target two fifty seven thirty or Treasury form the TD nine count bottom if it were to close above the top of its profile one twenty five that would be a change in transit folks they do for the trader's ed show but it's off to start your Wednesday please have a wonderful one we'll look forward to speaking with you again soon


Check, check, okay. So I think we're gonna get started. Thank you all for coming We're standing between you and your afternoon cocktail. So we'll try to make this lively and engaging My name is Greg Holzerter. I'm the CMO of big switch networks And I'm joined by a great panel here of both operators and as well as service providers We're gonna talk about neutron and experience working with neutron in the real world I know that that's a very hot topic and one where people are exploring How do you get scalability? How do you work through some of the the challenges and opportunities of neutron? And without further ado, we're gonna kind of head go ahead and jump right in and introduce the panel So Christian Sarenson is the CEO of clean safe cloud. He'll talk a little bit more about what they do Dallas Thornton is a deputy CEO of Clemson University Dimitar even off is in the office of the CTO from TELUS And we're joined by Wang Wei who's a CD SDN architect from united stack based in China So why don't we go ahead and have the panel introduce themselves and a little bit about their environments to kick things off Hi, good afternoon everyone. So yeah, I'm Christian Sarenson. I spent something like 19 years working as a software developer in the Finance industry from my sense Road things and did and architected things like law latency trading systems, for example For tier one investment banks Last year or perhaps about 18 months ago I had to relocate from from London, UK where I was based to back to Switzerland, which is my home country And question was well, what next? And it turns out that certain mr. Snowden is actually Gifted Switzerland with a with a great new USP as it were Which is which is you know the fact that Switzerland despite being in the middle of Europe is Outside of nsa and gchq and whatever else jurisdiction. So, you know for people who care about Privacy etc. It's quite an interesting place to put your data And this is how clean safe cloud was born Hi, I'm dallas Thornton. I'm a deputy CIO at Clemson University I've been there about two years and in that time one of the big things you've been working on is Sort of designing our new pod and hosting infrastructure We do sort of the typical university mission work But we also support a lot of research users as well as support hosting for a lot of government agencies in the state So we've been doing a lot of work with that Our big use case that we sort of started us off here aside from the pod design was virtual desktop usage so We we wanted to build something that would allow us to You know, especially with the network side of things It's supporting vdi which in a university environment is very Very spiky in in in terms of usage. So That led us to to working with these guys on Developing that out and building on top of open stack And hi everybody. I'm Dimitri Ivanov. I work for tell us tell us is a telecommunications provider in Canada We are Headquartered in Vancouver, British Columbia. We have about 8 million wireless subscribers about a couple of million High-speed internet subscribers About a million tv subscribers. So that gives you an idea about the The size of the company. I work for the office of the of the cto. I'm a I'm a cloud architect for the last Two years. I've been Yeah, focused on developing cloud architecture for a you know private cloud environment to use in our You know for the internal business units at tell us You know the primary one of the primary drivers there many of them But uh, you know kind of the more sizable one I guess is for our tv service kind of we're looking at a You know a pretty sizable cloud. I I can't even you know Uh Kind of disclose the size of it and all that but uh, it is a pretty sizable environment that we we're building Afternoon everybody, uh, I'm one way from united stack. I'm the austin architect We provide all public open-stack cloud and the private open-stack cloud in china and Uh, we have about Nearly 100 Customers which we provide the professional open-stack service and the most the biggest customer run about 500 Hippo razors in purely open-stack And as for me I have made contribution to new trend for two years and Uh through these years I we have seen the new trend has grown fast, but made some problems I will share this experience and the problems or the Tricks to to you. Thank you Great. Well, that picking up from that. Why don't we go through the experience of you know starting off working with open-stack and and neutron With you christian. What was the uh, the reason that you kind of looked at open-stack or the issues and problems that you were trying to resolve We had great luxury in as much as you know, we basically built everything from scratch Which I realize is certainly not, you know, everybody's uh Luck, uh, but it was ours. Um, so so we were able basically starting out in sort of flay 2014 So ice house time frame to select An architecture and an infrastructure which we were hoping to be as much open source as possible no vendor lock-in and flexibility being An absolute Top goal that we had because you know, we were just starting out. We we were talking to some customers, but By and large it was very hard to anticipate at the time what we were Going to have to deliver for those customers say even six months down the line So really an architecture that's based on on on everything software defined and that obviously includes software defined networking Was extremely appealing for us and that's that's how we kind of came to Open stack and hence neutron. I mean in in the ice house Which was our first proof concept time frame neutron was already pretty well established and it was pretty clear that you know That was going to be the the only game in town a few a few months down the line That's great Dallas. You might talk a little bit about the background in your environment Sure. So, you know, I mentioned our vdi use case and that's really kind of what what initially drove us Our issue was a lot had a lot to do with licensing and you know having 20,000 Students out there and another you know 6,000 faculty staff You know the use cases for vdi and the cost on a per user basis for a lot of the vdi solutions that were out there were prohibitive So we're looking at you know, how do we do this in an open way and build out? You know a vdi environment that allows us to deal with a lot of the custom software that's it's out there in academia That you know in a way that we could manage and scale out sort of as needed And so open stack really allowed us to do that That's great. So you had a vmware environment and you were looking at moving into open stack then Correct. So a lot of our legacy hosting environment Was and still is vmware And so this was sort of you know, how do we actually roll out a new service in vdi on a new platform and using open stack for that Fantastic and demitar what um, what do you in terms of the background for tell us? What was the the reason for kind of looking at open stack and the background there? Yeah, much of the same reasons the guys already mentioned that you know with us being a service provider You know, I presumed most of the You know, if you know that The service provider had been kind of adopting for the last few years open stack for You know for any vnsdn so as being a service provider we're not Kind of we're not different. We kind of we we we follow that same same trend So selecting, you know open stack for us was kind of the You know pretty much, you know, I would say kind of no-brainer From that point of view because we obviously it would be you know, we don't want to develop Two different platforms for you know, any v or cloud so And but that's not the only thing though the You know, what what was just mentioned about you know being as much as you know open source and Kind of void any Or as much as possible You know vendor lock-ins from the perspective of The underlying infrastructure, but also from the you know the app for the actual cloud control air And that was the you know, that is the real driver, which is the you know the driver for In the reason why the the service providers are adopting open stack in in a first place In you know, if you want to develop You know software Software define everything You know open stack is really it is pretty much the only the only game in town The you know because the You know Amazon or microsoft or all the public providers that you know have invested in proprietary solutions You know, they're not they're not productized right so You know it is it is great that we you know we We have open stack and you know Should be grateful for it. So That's great. So, you know when you have a unique perspective being in china and Being with an organization that really is at the forefront of delivering open stack solutions. Can you talk a little bit more about you know Talking through the evolution of neutron and particularly the adoption in china and some of the the challenges and opportunities Okay, as we know that networking open stack from the no one network. It's pretty stable, but it's too uh, too small and as a feature is too too Too short and then community pushed the newtron the newtron project from about ice house or the journal and From the the newtron is pretty Well complex everybody will say that it's the the reference Implementation is from the is ova spaced it has many complex components and many which are network network devices And then the community has put the newtron to a framework or a platform And there are many new projects around the open stack like Dragonflow like ovm and open daylight and now the community seems more and more excessive and fruitful and You can use newtron as a framework and the platform not to use as it is a Astien solution. It's a Very exciting trend and we think it now makes the astien in open stack more and more healthy That's great. I'm going back to you d major. You say in terms of your experience With open stack and and with newtron in particular in your deployment You know, what were some of the the key kind of findings that you discovered along your Journey in terms of poc. It's something that you didn't expect to find Um You know, there wasn't so much that we you know, we didn't expect to find they wouldn't you know any any big surprises the You know the challenges of uh, you know in terms of deployment deploying, um, you know networking solutions for Uh, you know virtualized networking in general, um, you know specifically with with newtron They're not they kind of they've quite well documented. So, uh, you know, we try to you know, avoid those surprises from You know, just with just with research and and you know, making sure that we we learn from other people's You know challenges so we From from that perspective, I I can't really think of anything that we Kind of that happened that we didn't and didn't we didn't anticipate, but uh, it it was a Really Kind of You know in a in a good way to kind of find out that we that they are solutions out there that can help with with overcoming these challenges specifically, you know with that that we You know If you're building virtualizing virtualized solutions, uh, you know, one of the things that you have to do is You obviously have to have a network that you run on, right? and Managing of that network is something that you have to You have to do regardless of what solution you have in place and and having a solution that is Um, uh, that is manageable that it it helps you to Helps you to scale and at the same time Uh, it reduces the uh, you know reduces the complexity of the Of your deployment and the ongoing management is extremely important So that's the kind of the one message that I would You know, um kind of that I found for for ourselves that uh, uh, you know, there are many solutions that that will work um, but You know some of them require just more, um, you know more involvement and some of our, you know, less Kind of more manageable and uh from that perspective You know, they easier to they easier to deploy Got it. Great. So so dallas in terms of your experience when you are looking at deploying You know using neutron and open stack Did you come up with uh, did you come against scaling problems or are there ways that you kind of got around those challenges? Yeah, I mean, I think again our big use case in vdi. We're looking at you know, how do we get away from all the encapsulation problems that we had you know initially You know looking at this using traditional sort of fabrics and uh, so, you know Rolling rolling that out along with um, you know, the big switches and sdn Paradigm it really allowed us to overcome some of those issues I mean honestly, I think that the biggest thing we learned and are still learning is kind of the human factor side of it and You know the fact that you know, we had a network team that always did things and there was tickets that went to You know One person that went to another and and it's really, you know, for us it's been all but how do we automate the whole process and and Really get a lot of the bottlenecks out out of the system um, and you know, you know, that that's a not not Not as much of a technical problem as it is a as a as it is a process problem and it's something that you know I think we're making progress on and People are learning new skill sets and again. I think it's it's a human A human learning thing You know that was interesting in the in the keynote on uh, monday There was a conversation about you know 10 technology 90 percent sort of organization Could you comment a little bit more about you know before and after in terms of your org? How did how did that change? What did it look like before and now?  I mean we call everything and And basically the whole provisioning process can now be automated. So For us that it's a big paradigm change. It's you know Changing people's world a bit. But at the end of the day, I think it puts us in a lot better A lot better state That's great. And and christian could you maybe build on you know, some of the existing Challenges and then you know, what are you working on as your your next? Your next milestone your next goal Sure. Um, well in terms of challenges what we've found out is that I mean and I guess it doesn't come as a surprise, right? You're at the end of the day you get what you pay for in this instance You don't pay much. Therefore you shouldn't expect too much Which is actually, you know, in essence you get an awful and you know, I think I think we're all here extremely thankful To all the people and all the corporations That put all of this extremely hard work into making this stuff work, you know, so well out of the box In our in our case, I had you know, as I mentioned earlier, I was as I was a software developer I had very little experience of what I call the dark side of it at the time Which which is infrastructure stuff, right? And and you know with with close to zero experience in networking, etc.  I I didn't even know what uh, you know, what what one of these 10 gig ethernet cables I'd never touched one in my life, right when I had to patch these into racks I mean that's the beauty of startups you get to do a bit of everything and you just you just learn all the time But you know in terms of there's going to be rough edges, right? So for example, one of the things we found out with neutron is we wanted to use the neutron metering agent to You know build for bandwidth as providers do Um, and we found out they was well, I certainly couldn't find a way to get it to filter out certain um IP ranges So for example, if the customer was going internally to the object storage network I didn't want obviously to charge them for external bandwidth that kind of stuff.  I think this is one of the area where where perhaps things can always be improved I mean the ask open stack thing is is not particularly Vibrant I find compared to to other ask communities out there Um, and you know, you figure out a work around you document it and hopefully Going to your point, you know, what we hope to be doing somewhere down the line really and particularly with my background as a developer Is to start contributing back to the community. So, uh, so, you know, we we get to pay back a little bit All of this amazing tech that we get for pretty much free That's great and sort of you know kind of building on the concept of contributing So when maybe you can talk a little bit about some of the Feedback that you're getting from some of your customers in terms of asks and how you're contributing into the the Neutron project okay, and We know Neutron is awesome Since they're they have a very good community. They have active developers. They have the industry sport and The Neutron is a poorly so to be already find no wonder locking. There's all features that What our company or our customer like? But as you know, Neutron has some disadvantage as taste decides like it's lack of the physical manage From the previous previous release Neutron has a new Uh feature named Hirachi port binding. It's about the to ours To ours information binding, but it's not enough and we what we need is Manage the physical and the virtual networking both and it will keep the networking clean and more And more efficiency, but now Neutron takes the virtual Virtual role, but the physical is just we assume that the physical is always work Well, but the real world is that the physical network is not always well And we need some people like an infrastructure team or a networking team to operate the switches cables and the Port our nicks and it's very it's very Not as you know, not as the except except as Our customers and this is I think the Neutron's The biggest pay point for the current Great and Dimitar in terms of some of the Thoughts and that we were talking about the other day around You sort of overlays and underlays and building on Wang's point about the physical network One of you could comment a little bit about some of the discoveries that you found along your journey Yeah, that is That is definitely an interesting topic and you know that overlay versus underlay discussions been kind of going on for a while and You know people even arguing, you know, which one's better, you know overlay underlay and The answer from my perspective is that they both have their You know, they use and their place and they're they're good for some things and they may be You know not use not not good for some matter use cases, right? So what I find out from You know Big switches, you know has one of the kind of one of the few solutions on the marketplace which actually virtualizes the the underlay and You know, there's two Aspects of that, right? First of all, you know, you obviously have a You know a software defined network right into the You know into the actual fabric which You know at that level Kind of eliminates the need to have to have an overlay at that level at the same time if you You know, if you have a number of a number of parts with, you know a With a virtualized underlay where you can have and this is where the You know kind of making the connection with with neutron is, you know, you have neutron Basically directly, you know talking to your, you know, azn controller that it manages your You know a fabric in At the same time if you want to if you want to interconnect the You know a number of parts that are You know in the same location in different locations that that's when you use a You know one of the One of the overlays But the other aspect of it is that the I talked previously about manageability is that, you know, when you when you have a You know a relatively Kind of large size, even not as large even if you know something like as a You know 4ac, you know pot you still have about, you know in a Spine and leaf architecture you still have about 10 switches right not about but exactly 10 switches with you know to Spine and for leaf so You have two options you either You know Build that fabric either layer two or let layer three, you know manually and you manage it once which at the time or You know, you have a you have a solution that that manages that for you and You know, this is what I kind of see as a as a as a big advantage of You know of the the solution that big switch has is that It really reduces the complexity of manage the managing that fabric to the you know complexity of You know pretty much the complexity of managing a single switch And to me that's a big big advantage because now I can have You know somebody like myself. I don't consider myself You know a network admin. I'm more of a generalist And so I it is it could be a challenge for me to Not so much to build I can probably build it but to kind of to manage and maintain a You know a relatively large fabric But I know that I can manage a single switch And so we can manage a single switch I can pretty much, you know with with with some help for you know solution that You know Kind of takes that away from me and reduces that complexity to manage a single switch I know that I can do that and that kind of helps with the adoption of the of the of the technology because now I can have a You know a relatively small team that that manages the entire solution as opposed to Kind of the siloed You know solutions that we or Organizations that we we kind of we have in the legacy environment. So Great question. I think if I can add a little bit to this from me I mean, we've got really very different perspectives. I suppose Me being a startup you looking after, you know, a A major sort of telco operation But at the same time, it's funny to see that we've got, you know, very much the same kind of concerns Which I suppose are the kind of concerns that a lot of us are going to have and in our case, you know, being a startup Well, what matters a lot to startups is is Cap X and OPEX, right? and being able to Well, first of all, you're gonna have to have Neutron is all well and good it but it's at the end of the day still software and somewhere You're gonna have to have some hardware to run the network on And being able to do it all through a single pane of glass and thereby reducing complexity Really significantly. I mean from from a startups perspective where you've got about 10,000 things to do at every single Point in time. I mean that is fantastic. I have to say it's and and also The ability to see that this is a solution that will Accommodate future growth again from a startups perspective being able to start reasonably small but know that you're not locking yourself into An infrastructure that you're gonna have to throw away and rip out completely, you know, because because you're outgrow it Over time. I mean, I think that's that also is very compelling and if you can just add one thing and the the you know, the other thing is I'm not sure if it's I mean, it's clear to me.  It's not a it's not an actual, you know switch. So it does support, you know a variety of You know bare metal switches so you have a lot of You have a lot of choice from that point of view kind of selecting your selecting your own your own hardware and You know to to christian's point, you know that that helps reduce You know the capex significantly in terms of You know the the bare metal switches are significantly less expensive than You know the branded equipment that we are mostly familiar with Yeah, that's great. And so dallas, you know in terms of going talking about neutron and your existing environment Maybe you could talk a little bit about where are you taking this in this environment? What's your kind of growth? plan Sure, so our initial work was done sort of in a pilot mode with you know several classes that had specialized software What we're looking at going next is taking this into our hbc environment. So we've got you know 3000 4000 nodes of a compute infrastructure that we'd like to be able to utilize for for our bdi use case Again, when we have these kind of spiky workloads It's nice to be able to throw it in a pool that can absorb it and a lot of the the research workloads can be preempted And and so the idea being that we would deploy open stack into the hbc environment and Then you know again using the same technologies we've been talking about be able to scale the workload into there That's great. And in terms of Some of the feedback that you're getting from Conversations from customers. Where do you think? You know the trends for adoption around open stack and neutron in china it's looking like Uh, as I mentioned before the new train is trying to make more and more open and Become a framework or a platform so customers can get more and more choice And since the community has to make the default reference implementation May change from the oas to relax bridge. This means that What you can choice is one Is is more than the linux bridge or open way switch you can choose Like a big switch you can choose like ovm or another software based sdn solution and even you can choose some Switch or hardware based sdn solution likes from cisco likes from jonifer and what customers needs is stable and performance and scalability and such as such as this They may pray for software or hardware, but the Final result is that's what I mentioned the three words the scalability performance and the reliability yeah, that's great and to Dimitar going back to talking about futures and sort of where your project is going we have heard a fair amount about the Verizon red hat the big switch use case and NFV is maybe you could talk a little bit about scalability and what you guys are building out Yeah, sure. So kind of what we're looking at is a You know a typical, you know cloud cloud top environment with you know a couple of geographically distributed data center regions and a number of availability zones in each of the regions we are You know in in in our case the availability zones kind of equal to a pot You know a pot would have a You know a pod interconnect and A number of you know computer storage resources connected to the interconnect And that will be kind of one The building block of the of the of the cloud if you will that will be in Kind of subscribing to this to the you know core and port architecture where You know you minimize the The size of your full domain to the size of the the size of the pot And this is directly driven by you know some of the some of the requirements that we have in terms of the You know the availability and the resiliency of the solutions that we we have to provide So That's you know, that's pretty much pretty much it from from that perspective great Why don't we do kind of a quick sort of lightning round on you know if you could do it all over again What lessons learn what would you do different christian? And then we'll kind of go through the the panelists and then open it up for q&a Well, I mean we're still very It's still very early days for us But I think one of the things that I've certainly learned and I've got lots of input from from the summit here is Upgradability obviously is a major concern how you initially deploy your cloud is going to constrain this very much Neutron being one of the more complex pieces to upgrade particularly without downtime And I think you know, we would take a different approach to deploying the cloud We would do something a little bit less monolithic Perhaps based on ansible the open stack ansible for example And that that would definitely be something that we would I mean, I'm kind of thinking well, we're going to have to sort this out somehow So I guess I won't speak to the vdi use case but for our general sort of open stack hosting environment I think one of the big things that would have done first is inventory the pets And you know, I think we've got a lot of applications that aren't really designed to work well in an open stack environment today That we're sort of going through and looking at now And so, you know, we've had sort of an ongoing We have sort of our pods are in hybrid mode right now where it's, you know, a lot of vmware and a little bit of open stack so You know really it's going through and doing that inventory up front and starting to re architect a lot of those things to Work in a more fault tolerant way. So From from my perspective one one of the things that you know, I would change and that would be would be you know, difficult to change would be the kind of the Governance process that we have to go through, you know, in our own organization on their Another thing that is more kind of within within my control is to To spend we spent quite a bit of effort, but I would have spent more in terms of You know, bringing, you know, other teams In specifically in operations Earlier and kind of educate them and And make them kind of more enthusiastic about You know these these paradigm change. So it's it's it's a big it's a big cultural change And getting everybody involved, you know, early in the processes is critical. So that's one thing for sure that I would have approached differently That's great. Wang any parting comments on things that you have seen some of your clients You wish that they had have done differently or what was the top sort of takeaway for Issues to to avoid There is a there is a thing that's need to say that Many people say that ASTN there will there will be a revolution. It will Cure all network engineers, but the reality is that now we use the ASTN technology in open stack mostly the software based is still needs the hardware operation and it will not make any result to the Network the traditional network operation. So If if the ASTN solution should be more productive should could In fact the virtual and physical both way and then the The result and the operation or develops of the open stack and networking will be Big change Fantastic. So we're going to open it up now to q&a. We have a nice geographic representation A variety of different operators and contributors And I see that we have a question. So go ahead Um, yeah, my question has to do with the Throughput of open v-switch. There are many Technologies for bypassing the v-switch like dpdk or s r i o v or pc i pass through Do any of your applications need More throughput than open v-switch, and are you going to these bypass technologies? Yeah, I can probably address that quickly so With the big switch it it's solution. It's actually not using open v-switch. They there is a It's specifically if it's a switch light virtual is the Is the virtual switch that is basically replacing open v-switch is still using by the way the the kernel The kernel kind of portion of open v-switch, so it doesn't require You know additional changes to the kernel But at the same time it does replace the user space, which you know, which is where the bottleneck is in the first place So it doesn't by definition use the open v-switch And I get this right Yeah, that's right and then but in time But I was going to ask in terms of building on his question the the types of applications that you have in your environment that that require that type of throughput Oh, the the types of applications they're you know in a You know a private cloud environment, there'll be you know the full variety of You know enterprise class applications that you can imagine and you know some of some of them are more demanding for networking than others, but uh You know we we know that they are you know multiple that are really demanding to be you know for networking performance, so Not to translate the question Is 10 gig into the vm enough if it's not enough You may need to go to the bypass technologies Do you need to have more than 10 gig coming into the vm? If we need to have more than 10 gig into the into the vm, uh, realistically Um You know I have to be if You cannot get You know 10 gig to the vm Unless you go to something like s rov or you go to dpdk, right? That's what really so exactly so You you know and you absolutely need that if you you know if that's what you want to do And you know I've been talking to big switch quite extensively on that and My understanding is that the the next release of big switch will be Integrating dpdk, which will you know take it so so it's extremely important if you there was a there was a presentation with Verizon just before this one They actually talked about this because the in in their case they're deploying it for You know for any v which is actual You know networking workloads And for that it is you know, it is absolutely necessary I I'll have to you know kind of defer to somebody from From big switch as to you know when the dpdk integration is going to be complete. My understanding is with the next release, but I I see ken nodding so he confirms that That's correct Any other comments on the panel and on that question All right, great next question. Hi, I'd like to hear from each of you on this one. Um in the real world What do you do when things go wrong and how are you monitoring like Both the underlying the overlay or using what tools do you go to tcp dump using ganglia what What's your uh sense of the state of the art and how it how would you improve it? And thank you. I mean, there's there's there's lots of different approaches. I guess to this. I mean we we use traditional stuff such as sabbics for monitoring and the elk stack To collate logs, etc And I know that big switch internally also provides some great Analytics and visibility tools and again that goes back to the single pane of glass Whereby, you know being a having a physical plus virtual layer that actually addresses the entire spectrum Gives you great visibility Across you know across the boundaries essentially the boundary is just just just mesh into one which is Again going back to the simplicity argument. It's it's fantastic and it's it's kind of next gen stuff really and it's It's one of these things once you've experienced it. You you kind of wonder how you did without But yeah, I mean, you know a variety of things and strategies will will will work. I think well I haven't found anything that works well yet I think, you know, we I mean, it's this hodgepodge of stuff, right and You know if someone has the answer, please stand up. I would love to hear it But other than you know going out and spending millions for certain vendors who remain nameless Tools that say they'll do the job, but really want You know in the absence of that we're looking at, you know, basically pulling that data as much together as we can We're using Splunk for you know to basically suck in a lot of the logging data and then writing things on top of that to you know To look to look for the patterns and when we initially deployed our pods we've had all sorts of You know fun stuff that you find right and it's it's how do you figure that out and what it what it is and iron it out and So that's been tremendously useful for us So I'll go back to the the overlay versus the underlay the topic that we We talked about it is the so in this typically any You know overlay underlay situation if you're using overlay, what happens is the in essence you have two separate networks, right? So you have you have a physical network that you know, you might be managing or somebody else is managing Very likely and then and then you have your overlay on top of that so basically you have a virtual network and you know physical network and in many cases they The overlay doesn't have the Doesn't have any visibility into the underlay other than say it doesn't you know It doesn't work and and then and then you start troubleshooting in in this case and you know Christian as well dish on that in the case of a big switch you you you have a you know one solution. So basically The the the virtual switch that we talked about that is in the Is running Basically on the hypervisor is in fact part of the fabric, right?  I believe is exactly what it's called where you can you know Generate traffic from one point and just see it how it goes from You know to to another point both through the You know virtual and and physical physical environment and see exactly where it stops if if it does if you know If you're troubleshooting some problems, so Um, yeah, that's that's what I can Can add to that question or Yeah, Wang any final comments on that? Okay. I can add some comments that Uh, in my opinion, these are so far. There is no a perfect tool for Overlay networking virtual visualization You might you may be need to come by as you say tcp dump or ip wrote or net link or something Tools that you familiar with and Yes, it is pretty complex. There's no perfect tools to Monitoring Under over the networking Great. I think we have time for one. We're a little bit over about time for one last question Yeah, there was some mention of migrating existing virtual network and VMware Are to open stack Just wondering, you know, what are the steps you go through? Do you have to once again? Create network subnet interfaces things like that or is there a way to just Move the metadata have it point to the existing network take over the management Under open stack. How do you go about doing the migration? I guess Yeah, I mean right now it's it's not I haven't found a simple way to do it I mean as I said a lot of it it gets back to you know, how do we sort of untangle? As I my cto says the the spaghetti monster that is a lot of these applications and and really look at you know How do we really build them for fault tolerance and resiliency and In doing that I think it Means straightening out some of the networking stuff that's there now. We've got a lot of big big flat subnets that are You know that that are that are there and Trying to you know segment that out And you know, so what we've done from our Even VMware to VMware From sort of our legacy hosting environment into the pods is We do a temporary span to get things over and then start doing the rearchitecture in the new environment. So And the idea being the span goes away and you actually start managing those networks through In this in our case that big switch Great fantastic. Well, we're at the end of the time. Thank you all for staying and I wanted to thank the panelists For their insight and sharing sort of the lessons learned along the the journey of neutron networking and we're we're going to wrap Thank you so much