All right, well, looks like we should get it started soon. I appreciate you all coming by this late in the day. My name is Dan Willand. I work at VMware. This talk is entitled, Avoiding the Perpetual Proof of Concept, which I think was controversial enough that might get some people to come in. And in smaller fonts, Beating Enterprise opens stack adoption with VMware. So the reality is most of the time I'll actually spend on the main point. There's going to be a couple other sessions here at the summit that will talk more about VMware's offerings in depth. I'll cover them a bit at the end, and if we have time, give a couple quick demos. But the main thing that I want to talk about today is just try to answer the main question of, OK, well, between a POC and being successful in a real production, scale, multi-tenant, opens that cloud, what are the key kind of stumbling blocks and things you have to knock out of the way for you to be successful on that route? So a bit about me. I actually, this is, I think, my 10th open stack summit, if I'm counting correctly. All of them since Austin. I was involved in an open stack. It's part of a startup called NYSERA. And as part of that, we started the open stack networking project, which at that point was quantum. It's now been renamed Neutron due to a certain company threatening to sue us. And so I was the project team leader, Ptl, for open stack networking for two years. And now I have a role at VMware, which is kind of defining our overall open stack product strategy. That's across networking, which they acquired NYSERA. That was my original role. And now, but storage compute management as well. So with that, I think I'll get started. So what do I mean by this concept of a perpetual proof of concept? So how many of you have used dev stack before? Or any other simple tool to stand up open stack? It's really easy. You're down, getting a boon to VM or whatever. Copy and paste a couple commands. And next thing you know, you've got Horizon there. And you can boot a VM. And you've got open stack. And you can use the CLI and the APIs if you want. And it's pretty cool. But I don't know how many of you are fans of the internet meme, but this is a popular one going around about open stack recently. One does not simply deploy open stack. It's very complicated. And I don't know if any of you were at earlier so much when they're handing out these t-shirts. This is a personal favorite of mine. A common refrain from developers. Well, it worked in dev stack. I didn't test it in anything else, but it worked in dev stack. So I bet it probably will work in production. So these are all just kind of simple ways of saying, we all know there's a big gap between what you would do with dev stack or some other simple deployment tool. They're great tools if you understand what they're for. But you have to appreciate the jump between that and a full production deployment. So sometimes, I think, it can kind of seem like this, where with dev stack, you can see horizon. You can boot VMs. You can create users. It feels like you're almost there, like the mouse. And you almost have the cheese. But you have to keep turning and turning and turning and turning to really do everything needed to get to an open stack production grade deployment. So how about some data? Maybe a little proof I'm not just making all this up. How many of you check out the OpenStack user survey? Have you guys seen this data? It's super useful. I recommend that, A, you participate in it. If you're an OpenStack user, or at least check out the data. They typically have a session on it every summit and publish the data. So it's basically OpenStack users reporting information about their deployments. What you have here, this is over the past three summits where they've done the surveys. You can see in the red line is the total number of OpenStack deployments deployed. Great line, up and to the right, shows a lot of people interested, a lot of excitement about OpenStack. The green line is production. So pretty far down, but still not terribly bad. The most interesting bit of data I see in that data set is actually they started calling out numbers for production deployments over 500 VMs. Which to be honest with you, 500 VMs is not that big. Rack or two maybe. That number is almost flat. And the reality is that getting a small kind of basic OpenStack environment is pretty easy. But the kind of problems you start running into, when you go beyond 500 VMs, you get to 1,000 VMs, 2,000 VMs, 3,000 VMs. This is why we're all doing OpenStack. We're not doing OpenStack to do 20 VMs, 100 VMs. The type of problems you run into are very non-trivial problems. And typically require a very sophisticated development team to be successful with. And so really what I'm trying to do is help explain what are all the steps needed to be in one of those purple, be in that purple bar, rather than just being in that red bar. And I think this is concrete evidence to the fairly intuitive observation that many of us have had that's actually a pretty hard jump to make. I want to be clear, by far not the first person to be making this observation. In fact, probably the most useful thing you can do is check out a blog by the chief architect at eBay. Links down here. It was entitled, an OpenStack installation does not make a cloud. And the blog went on to continue and call out a whole set of things that you have to do beyond just taking the OpenStack code in order to be able to successfully deliver an OpenStack cloud. We're not deploying OpenStack for the fun of it, or at least most of us aren't, but we're deploying OpenStack to enable a set of developers to deploy workloads and get real business jobs done. And so the point was what are all the things you have to do between deploying an initial OpenStack setup to having a production-grade infrastructure for your business to be consuming and getting real value from OpenStack? And the logical conclusion was, yeah, there's actually a lot of significant time and energy you're going to have to pour into this. Now, from eBay, they were what I would call a do-it-yourself customer, so they built up their own internal team, built these tools over time. And that's certainly an option with OpenStack. Another option that we'll talk about later, hint from a product company, is that you can get a product that potentially fills a lot of these gaps as well. So I actually think, even though I like the wheel diagram, I actually think this is more accurate. You're the most you want to get to your cheese. And there's actually a whole set of stumbling blocks that you can get to. You can think, oh, I'm almost in production. I'm going to get that cheese snap. So what I want to do is I want to help you get to production OpenStack without any broken limbs. Think of it that way. And look, that's the path. So you might want to take a picture of this slide. Could be important if you plan on doing production grade OpenStack anytime soon. So where am I getting the data for this presentation? As I mentioned, I've been involved in OpenStack since it was publicly announced. So I've done deployments on Diablo. I've done deployments on Essex. And especially in the early days of OpenStack, that's how you felt after deploying OpenStack. You weren't sure who won. Maybe you got something up and running, but you were all bruised and beaten too. I think the world's a little better now. But I was kind of putting together my notes for this. I started listing out all the different customer deployments I've been involved in. And I stopped basically counting at 50. But I've been involved in a lot of different deployments. They've ranged from large service providers to tiny private clouds. Some have been by no means telling you that all 50 of those were successful. Sometimes people were successful. They got promoted or they moved on to another job, got a great title some of their company because of the success they had with OpenStack. And some of them, to be honest with you, weren't. So what I want to do is I want to help you understand how you can be one of those more successful people deploying OpenStack. And I want to be clear too, even though I'm from VM, or the actual data for this, I've been involved in deployments that are pure open source deployments. I've been involved in deployments that are a mix of open source technologies like KVM with technologies like the NYSERA technology, which is now called VMware NSX. I've been involved in mixed hypervisor deployments. I've been involved in vSphere deployment. So generally speaking, a lot of these points are generic across all of those. One data point where I've gotten really in-depth view is that VM were actually continues to run an internal OpenStack cloud. So now it's, I think it's over 250. 250 is a safe number. It's a multi-hypervisor deployment. It's a mix of vSX and KVM with NSX for networking. Any given day, it has somewhere around 5,000 VMs, couple thousand logical networks, depending on what we're doing on it. It's used for test dev. It's used for continuous integration. It's used for training our sales folks, training our customers, giving partners lab environments, used for all kinds of stuff. That's what OpenStack should be able to do. Should be a very multi-purpose tool. And in fact, today, I don't know if any of you went to the Neutron hands-on lab, which was I think just an hour or two ago. We actually had 200 different, unique, fully isolated lab environments that everyone in that hands-on lab was using. They're all hosted in this OpenStack cloud at VMware. Moving on, I wanna, just before we dive into the specifics, I wanna give you a little framing for what is OpenStack and how we think about OpenStack. So as I mentioned earlier, the whole point of OpenStack is to give a team who actually is solving a business problem, the infrastructure to solve their problems. So up at the top, you'll see what we call the application DevOps team, right? They're either writing scripts or using pre-built tools that use OpenStack APIs to programmatically talk to the infrastructure. The infrastructure here is represented in the red. This is what OpenStack provides you, a set of tools in terms of SDKs, CLIs, a web portal, all on top of these standard vendor-neutral OpenStack APIs. And then it's up to the cloud infrastructure team to decide what infrastructure lays under those standard OpenStack APIs. They'll have to pick a set of virtualization technologies. They'll have to pick a set of hardware technologies. Then they'll have to pick a set of infrastructure operations and management tools that actually help them keep the lights on and do all kinds of troubleshooting, capacity planning, security, and compliance, et cetera, to run a production-grade cloud. Make sense? All right. So this is the format I'll be using to go through a couple of the items I want to talk about. I'll highlight a kind of a key stumbling block. And then over on the left, what you'll see is the set of layers in the stack that that stumbling block typically applies to. And one of the reasons I did this is people often hear a stumbling block like scale. And they think only about OpenStack scale. They don't necessarily think about, oh, I have to think about the scale of the compute infrastructure, right? You know, if OpenStack scales infinitely, but my compute infrastructure doesn't, your overall solution still doesn't scale. Another good one, I have to think about the scale of my infrastructure operations and management tools, right? If I build an operations management tool that does something and it works at 10 VMs, right? There's no guarantee it's not gonna blow up once I get to 1,000 VMs or 2,000 VMs. So let's start out with the first one, which is someone should be very familiar with if you've ever installed OpenStack. Just the basic need to have OpenStack packaged up and installed and deployed in a highly available way. Highly availability basically for the OpenStack control plane would mean something like I have multiple Nova API servers so that if one fails, the other one can take over and load balancing across them, et cetera. Now, the reason I have this picture is that really you should think of this as the foundation of any OpenStack solution. It's entirely necessary, but the thing to be careful about is it's completely not sufficient. And a lot of times the discussion around OpenStack actually, in my opinion, in an unhealthy ways, is very just focused on this. Hey, you can use this tool, you can install it and it deploys OpenStack in a highly available way. Ta-da, production grade OpenStack. And so you really need to think about all aspects of highly availability, not just for OpenStack, but for your underlying infrastructure. And there's a whole host of additional things we'll talk about that in my mind are just as important for a production grade OpenStack cloud. So this is kind of the foundation of a production grade OpenStack cloud, but there's a whole lot more that you need to think about. Next one is integration testing and support. Now, there's many different models of how you can get this done. But what I mean by integration testing is who makes sure that when you pick an OpenStack cloud that has this type of compute, this type of storage, and this management tool, that it all works together. That it all works together when you first deploy it and that it all works together still when you apply this bug fix over here or that bug fix over there. And it still works together when you decide to upgrade the hypervisor to the new version because you heard the performance is better and that it still works when you upgrade to the next release of OpenStack. And from a support perspective, what do you do when you have a tenant call in and say, I'm getting poor networking performance, what's going on? Or, hey, the Nova server is returning a 500. These issues could happen anywhere in the stack, could be in the OpenStack control plane, could be compute network storage. And really there's two basic models to this. You can build that capacity inside in-house. That's what I would call the DIY model. Seeing people succeed with that. Or you could go to a vendor, right, who would provide OpenStack integration testing and support on your behalf. I would say that I think this is the area probably where I've seen the most drastic misjudgments from people in terms of them minimizing the anticipated complexity of what's going on here. They tend to think like, oh, someone probably tested this upstream. So it'll probably work in my environment. And you saw that slide with the bruises. This is where a lot of those bruises came from. Well, it turns out the person developing upstream thought they had this version of NSX whereas the customer was deploying this version. This is actually complicated stuff and it's non-trivial. So you either really need to decide to build up this own capability. That usually means running CI, continuous integration infrastructure in your team. We know people who have done that successfully. That typically means building up a team of developers and DevOps folks that are very OpenStack, Python, Linux, Savvy. And often that takes a lot longer than people expect.  Well, you know what the problem is. Everyone else is also thinking, I'm just gonna go hire five OpenStack people. And so this is something that can definitely, if you misjudge this, can definitely, if you go the DIY route and you misjudge this, this can definitely kind of blow out your timelines in a very serious way. I think the other thing to call out, too, is to think about, when you're thinking about support, thinking about the interactions between support between if you have a multi-vendor solution. Again, people kind of think, okay, well, I'll get OpenStack from this person. I'll get my hypervisor from this person. I'll get my networking from this person. Without necessarily thinking about, okay, well, does the person I'm getting OpenStack from sufficiently know the underlying hypervisor platform well enough to know that if there's a bug in that driver, which they probably didn't write, how to fix that bug and patch that bug. So these are all very mundane and kind of boring issues, but the reality is a lot of the damage in terms of what people perceive as OpenStack being unreliable in this. And that actually really comes down to this core issue, and whether you're properly covered from an integration testing in a support perspective. Like I said, you can do that multiple paths.  Second one is, or next one is rolling upgrade. I actually, to be honest with you, kind of find it shocking that, I'm not gonna name names, that's not my goal here, but there are major OpenStack distro vendors out there today who actually tell you that you cannot upgrade their OpenStack, right? OpenStack's four years old, right? Like maybe when I was one year old, two year old, I get that, it's over four years old, right? And they say no, just deploy another one next to it, right? And start putting workloads onto that. So this is a question, whatever your approach to OpenStack is, I always ask them about rolling upgrade, because this is something that a lot of people jump into production is they say, hey, I can go into production with this version without asking what's gonna happen when that version changes. And asking, for example, whether their vendor, how does their vendor's code relate to the upstream code? How soon are they gonna release after a given upstream release and have an actual product around it? This is very, this is more data from that OpenStack user survey. You can see, so this was from the last summit which is the most recent available when I put this together. So Icehouse had just been released at this time. So you can tell about as many people were on versions older than two releases that were on the most recent two releases. So again, pretty strong data, right? That people see upgrade and rolling upgrade and the ability to move to the next version of OpenStack as a pretty key stumbling block. Performance validation. So in a POC, what do you do to test? Well, I can think about when I did it, I probably use the Horizon GUI to boot up a couple of VMs. You know, went into those VMs, did a couple of pings, made sure that everything worked and said, okay, that's pretty cool, right? Well, it's very different from what you need for a production grade OpenStack cloud, right? You need to understand the core OpenStack control playing performance. What happens if I boot 200 VMs, right? Is the OpenStack control playing gonna keel over or is it gonna be able to handle the load? I can tell you, it certainly depends on how you deploy and how you spread out those services.  Similarly, you know, on your core compute network storage infrastructure.  I bet it's still true. I just don't run the networking project anymore, so I haven't tested it. But, you know, subtle differences in how you configure, for example, OpenStack networking, whether you're using tunneling, whether you're using security groups, how do they combine, can easily result in, you know, four or five X difference in performance. So you need to be very, you need to really understand the trade-offs between different configurations and make sure you're really validating the performance of your desired configuration that it meets your needs. Obviously, you know, you can validate performance on any one of these areas. You know, storage performance is a performance good enough for running a database server. You know, is that something my application requires, et cetera. But definitely being able to do a good burn-in, understanding the characteristics and what type of performance guarantees you are aren't able to provide. It's a very key thing to do between POC and production. This is another interesting one. There's a lot of options in terms of OpenStack, right? Everyone knows OpenStack's all about choices, right? And you can choose what back-ends you want to use and you can even choose what OpenStack services you want to use. So, you know, the first question is just, well, what OpenStack services do I think I need, right? So, just to take a survey, so let's just do a level set. So, how many people have deployed OpenStack with Nova? Oh, more than that, no, really? Oh, come on. Okay, then there might not be much data because I'm gonna ask even more obscure things. So, how many of those have deployed with Swift? How many had a need for Object Store? So, a lot less, right? Now, whether you need to do that or not, right? Depends on the set of applications you're running.  It's not a statement about whether Swift works or not. It's a statement about, you know, whether that service and that capability is something your cloud tenants need. How about heat? Heat, okay, so it's reasonable. That's about what I would expect. You know, we're starting to see people moving into the phase where heat's at least a core part of what they're planning on doing in the future, even if they're not deploying it now. What about Trove, database as a service, anyone? Okay, that about maps to what I would have guessed. You know, we're starting to see some people dabbling with Trove and asking about it, but, you know, most people are really just trying to get the core stuff working and solid at this point. So, that's just the first basic question of which OpenStack services do I even need. Your POC probably spins them all up, right, because it doesn't have to worry about creating them in production grade or tuning them or anything. The next thing is to say, okay, well, you know, if I think about the flavors and the needs of the specific applications, what are they? Good example of this, how many of you heard about the fact that Amazon had to reboot, you know, 10 to 20% of their VMs? You guys hear about that in the news at all? It turns out supposedly it was some Zen, some bug in the Zen security issue and the Zen hypervisor that they had to reboot. No, I don't think they officially said that, but anyway, the point is Amazon basically has a SLA to their customers that says, you know, we can tell you we're gonna reboot your VM whenever we want. We'll try to give you some notification, but you know what, the server may go down in which case you get no notification, right? That's an SLA between the cloud and its users. You have to decide if that type of SLA is something that's relevant to your users or if you wanna build a cloud platform that can guarantee that a VM, for example, is preserved, right? Does it have shared storage that if a hypervisor loses a disk that VM's not just gonna go down, right? Does it have something like maintenance mode to live migrate the VM off, right? These are things you have to think about. You have to say, what are the types of applications that are going on this cloud? And therefore that dictates a lot about how you need to build the underlying infrastructure. Another example is just standard performance tiering, right? You can have, for example, sender volumes. You can have different sender types. So for example, if I'm a database, right, I probably really care about the IOPS so I'm gonna get off a volume. I wanna be hitting fast storage, likely either all flash storage or storage that's really accelerated by a good amount of flash. If I'm just using a volume as a backup mechanism, I probably don't care, right? What type of tiering do you need to do in your application? And do you have an underlying infrastructure that can support that type of tiering? I could probably talk all day about this, but I'll move on. User and quota management. This is one that's almost always overlooked in small private clouds. Obviously, if I'm a public cloud, this is a core part of what I do. I have a sales pipeline. I move that customer into the sales pipeline. I probably give them a free trial. I get their credit card info. So public clouds are all about user and quota management. But often private clouds, they're just like, hey, I'm just trying to get this stuff working. I'm trying to find some people who wanna throw some stuff on here and, but before they know it, if your cloud's successful, pretty soon you have a problem on your hands, right? You've got a bunch of people who wanna access, they wanna get access to this project and that project and how do they do that? What's your mechanism for requesting access to a project or asking for a bumping quota and deciding whether to give it to them? This is actually something where typically people use really bad just manual channels like email to sort this out, but they aren't able to do it in a formal way that has approvals, that has visibility, that checks back and says, hey, you said you were just needed this quota for a month, you know, I'm taking it back from you. So, you know, thinking about how that whole workflow and approval process around your users, their projects, their quotas works is something that you'll wanna do before your cloud grows too big if you're truly having a multi-tenant cloud. Application life cycle management or platform as a service. This is about whatever you do on top of OpenStack. But remember, at the end of the day, your business problem isn't solved until you've solved all of the layers in this stack. So what is your strategy for your business case?    You know, am I actually gonna expose something that's a little more restrictive than infrastructure to service, like a pass, for example, cloud foundry.  Those are all reasonable things to do. You have to ask yourself for your business, for your business to be successful. You know, what's the model I should support here? This one's a huge one and actually something that people tend to overlook all the time. So, you know, you can, and again, you can tell almost all the boxes are lit up, right? You can think about infrastructure monitoring, troubleshooting, log analysis, alerts or mediation. At the end of the day, someone, if this is production infrastructure, right? Someone has, well, at least they would have had a pager. Maybe they just get their alerts on cell phones now. I don't know. I thankfully don't have to carry either. Someone else does that for our cloud.  And so, well, what are your tools? You know, how do you have visibility into the OpenStack control plane to understand its health? How would I understand if my Nova API servers are getting swamped or my end users are consistently getting 500 errors, right? I want to know about that proactively, right?  I'd say, wait, I should have known that up front, right? You know, that's just an example of the OpenStack control plane. Do you have a team who knows how to troubleshoot the compute infrastructure, the network infrastructure, the storage infrastructure, right? They have, you know, do they have the existing tools to monitor that, their entire processes around how that works, who they alert, who they go to for help, right? If you're starting with a Greenfield cloud, you actually have to build all of this from the ground up again. And so, this is something definitely, definitely not to overlook. And log analysis, anyone who's worked with OpenStack in production knows, it spews out a lot of logs, right? So, you know, you need a good tool for being able to not just centrally manage those logs, but search them, have triggers off them, have alerts off them, et cetera. And this is very critical to being able to run a good OpenStack cloud in production. Scale, right? Like I said, you know, if you're gonna be, we're not interested in clouds to handle a couple VMs, right? Those are things you can do manually. Ultimately, the reason most of us are building OpenStack clouds is we imagine this large scale-out pool of capacity that our business users can just draw from as they need, right? We can throw additional chunks of hardware into it as needed, and it scales out. But of course, in a POC, right? You're probably not scaling the OpenStack control plane. You're probably not scaling the compute layer. You're probably not scaling the network. You're not testing any of that, right? And, you know, there's an incredible number of issues you can run into here. Just mind-boggling, really. And I actually believe, if you look, one of the reasons I think so many people are at that under 500 VM limit, is that that's, you know, an area where you can still get away with simple flat networking or simple VLAN networking. You can probably get away with having maybe a single network node with active passive. You don't have to figure out how to scale out your networking nodes, right? There's all kinds of scale at the OpenStack control plane, at the networking layer, at the storage layer, that you have to understand kind of what you're getting into and to what degree those underlying platforms have been validated to operate at scale and in the configuration you're using them. And of course, the sister to scale is performance at scale. That's a great story here. How many of you have ever looked at the load balancer as a service in OpenStack? Anyone yet? Okay, so the default implementation of this is I'm not kidding. It's a single, it's basically a Python process that every time you create a load balancer just creates a Linux namespace and starts HAProxy in it. So, you know, if you create one load balancer and try to pump some packets through it, you can probably do pretty well.  There's no way to guarantee a load balancer in any sort of capacity. There's no way to make it scale beyond a particular host, right? These are all things you never find out in a POC, right? You actually have to go do the validation at scale if you're in the DIY model, right? Or work with someone who has. You can understand that, well, if I pick this driver, right, it can scale in this way. You know, there's OpenStack control plane, right? You know, all kinds of POCs, right? They just jam everything into one VM because it's super simple. You can download a VM or you can run this single DevStack command in one VM, right? The behavior of your, you know, the queues between services and if you're ever pounding on that control plane in any non-trivial way, like your developers will when it's in production, that model will never work. You need to farm them out into different, you know, either hosts or some other mechanism that guarantees them capacity, right? And that lets you scale out and give sufficient CPU and memory and guaranteed resources to each of those components. This is an interesting one. It's another kind of thing that you don't typically think about during a POC, right? But you need to think about, okay, well, yeah, maybe I'm just starting out with some non-important workloads here. The second I prove that this cloud is successful, are people gonna wanna put more and more stuff on it? And maybe suddenly those new workloads start having personal data in it, right? Or credit card numbers. Or anything else that I actually have to care about security and compliance. So this really comes down into, you know, either security and compliance at the OpenStack control plane layer, right? You need to make sure that, you know, either the distro that you use or if you're doing it yourself that you've properly made sure that all, you know, inner service communication are using certificates over SSL, right? You need to make sure that all the passwords are set in a secure way and can be updated. You need to make sure that you have a process in place to react to a security advisory that happens inside of OpenStack, right? There are all things that again, you know, if you really, if this is really gonna be a production cloud you need to care about. And then obviously that goes all the way down if anyone's ever had the joy of dealing with security and compliance, right? You know, that goes all the way down your stack. Change management, this and that, right? Making sure that you have the proper controls in place if someone ever modifies the compute infrastructure that you can prove that you've limited access to the underlying infrastructure to the appropriate set of people. All of that. I hate security and compliance so you can tell I'm moving past that one quickly. Yeah, capacity monitoring, capacity addition, right? The cloud you start with is not, you know, hopefully gonna be the cloud you end with. So how do you monitor and find out that, oh, I'm running out of compute capacity, I'm running out of capacity for my volume. So I'm running out of capacity for my high IOPS volumes but I have plenty of capacity for my, you know, cheap storage volumes, right? These are all things that, you know, you don't wanna find out the answer when someone says, hey, I failed to provision my workload that I need to have done for my, you know, for my job tomorrow, right? You need to be proactively monitoring and understanding this capacity. I need an easy way to add that capacity over, you know, when it's needed. The final one is, or final or second to final, I forget, second to final now I think. It's cost modeling invisibility. So, you know, it's about having visibility into the cloud. How much does it cost?  And finally, there's a whole bunch of miscellaneous day two operations that you need to think through. I was just talking to someone today, said, oh, well I have to think about the case where I upgraded the BIOS and my hypervisor and what impact that has on my workloads. All right, it's probably not something you would have thought about during your POC, but something you definitely need to think about before you go into production. So, going back, and like I said, I'm not gonna spend a whole lot of time on the VMware side, I'll end with a slide that shows you lots and lots of different VMware talks you can go to to learn more. But this is the basics of how VMware technology fits into OpenStack. From a compute perspective, you can use vSphere. From a networking perspective, you can use NSX. Storage, we can plug into the vSphere storage APIs and use whatever storage works with your vSphere environment. We have lots of infrastructure and operations management tools, vCenter operations management, log insight and IT business management for the cost visibility. I'll go in another slide and kind of explain how these things map to the problems we just talked about. There's vCloud Automation Center and things like Pivotal Cloud Foundry depending on the model you wanna provide your application development teams. And then you can get OpenStack from anyone, you can get it from open source, you can get it from a third party vendor. And recently VMware actually announced its own distro of OpenStack for people who are really looking for a more tightly integrated solution. We call that VMware Integrated OpenStack. So just one more slide on what is VMware Integrated OpenStack. It lets you start with your existing vSphere environment. You add VMware Integrated OpenStack which is just a hardened version of the upstream code running with the VMware drivers configured and a really simple install and upgrade process. That makes it very easy for someone with an existing VMware skill set to be able to leverage and deploy OpenStack. And the key thing to realize here is you're deploying OpenStack on top of your existing vSphere environment where you already have many of those things that I talked about earlier figured out. Well, I already know how the system performs. I've already created different tiers of storage. I already know how I have security and compliance figured out there. I've got a bunch of tools for troubleshooting it. And so this really lets you vault past a lot of the hurdles that you have in OpenStack and deliver OpenStack to your developers quickly. And then finally, we provide a lot of OpenStack-aware cloud management. These are things like VC operations manager login site, several of the other tools I talked about earlier. You know, and again, these are filling kind of key gaps that aren't necessarily an OpenStack itself. These are things that go around OpenStack but help you run a successful cloud for your company. And then what we do is we put it all in a, scale out HA validated reference architecture and we provide a single contact for support. Because the reality is when you have a problem, you're not gonna immediately know whether it's a problem in OpenStack or OpenStack's giving you an error because it's a problem in the underlying infrastructure. And so it's very important that you're able to go to one person, you're not getting ping pong between different vendors. So again, this is an example of a, there are many different ways to consume OpenStack with VMware. This is an example of a very tightly integrated way, right? We have customers who take the open source code. We have customers who use third party distros and we now more recently have customers who follow this model as well. So going back to the things we talked about, you know, I already mentioned some of these in passing but these are just the different components of the VMware solution and what of those earlier problems they touch on. And again, you know, this isn't by any means a statement, this is the only route to get that. I wouldn't be so bold, but you know, it is saying that you do need to think about these and one of the ways you can solve these problems is by working with a vendor and VMware's got a lot of good technology in that space. So I'm actually gonna quickly just pull up. I wanna show a quick demo of VMware integrated OpenStack so you all could just get a sense of what that looks like and show some of the tools that I talked about. So there's no sound here but I'll just kind of talk you quickly through what you're seeing. So the simple install is that you basically just download a virtual appliance and then you can see up there in the upper right VMware integrated OpenStack is now kind of a set of tools you have inside of your standard VMware vCenter. And you can click on that and you can choose to deploy OpenStack. And that will take you through a basic wizard where you give it some set of IP addresses for the OpenStack services. You choose the clusters you're gonna use for OpenStack capacity and it will automatically boot up. You can see the VMs over there, a fully HA, fully production grade, scalable OpenStack control plane. So your end users can log into Horizon or use the APIs or use the CLI just like anything else they do. Now the important thing to notice here is that there's nothing different from a, this is nothing VMware specific about what you're seeing here. Your end users should get standard OpenStack APIs on top of really great production grade infrastructure. But you as an operator have a whole set of VMware tools at your disposal for doing things like troubleshooting, cost visibility, all those things we talked about. This is VC Operations Manager. It monitors the OpenStack control plane as well as individual VMs. These are tools inside of NSX to make network troubleshooting simpler. This is that login site that centralized log analysis tool with dashboards that are OpenStack specific. This is a trace back I used to troubleshoot some OpenStack problems a little while ago. I think it's the DHCP error or something. So anyway, we actually have a full dedicated 40 minute session tomorrow that you can go to and see a deep dive demo on that. I just wanted to give you that kind of little teaser trailer. So with that, I'll just show you the other, on Thursday we'll be talking a bit about some early reference customers. These are a set of people we worked with early with VMware integrated OpenStack to actually have production grade deployments with more of a high touch model. We're now in beta for our software that's more around the low touch model where a VMware administrator should be able to be successful with OpenStack without necessarily having a professional services engagement. But I'll talk more about these in our session on Thursday morning. That's the session in the upper right. Tomorrow you can see on Monday these sessions are obviously passed but everything's online. OpenStack is great about sharing those videos. So you can watch those on YouTube later. Bunch of sessions tomorrow afternoon. The deep dive technical demo is the second session I mentioned there. And then a couple other talks. Here are some great resources. Hands on Lab. VMware has this thing where you can actually click a couple buttons in your browser and we spin up a VDI session to a full OpenStack and VMware environment. Now it's not the production grade environment we talked about earlier. It's more that kind of demo POC mode. But it's a good place to start if you're looking to learn more about OpenStack and VMware. This is the link if you're looking for the product page or to sign up for the beta. And we also just have a generic OpenStack communities page where you can ask questions about VMware and OpenStack. So with that I want to say thanks. Open up for any questions. I think we're over but I'm not sure if we're the last session or not. So please let me know if we have time for questions. And this is my Twitter handle, my email if you have questions. And definitely if you saw this and said hey you totally missed this other stumbling block. Let me know. I'd love to add it to the deck for future use. So thanks. Any questions? All right well I'll play one more video for you in the background as you can stay or file out as you wish. But it's a video actually of showing how you can take VIO and which is again designed for using on VMware infrastructure but you can actually extend it to work with KVM deployments as well. And again the key takeaway here is that with VIO we support all the standard OpenStack APIs. And so if you have something else that also supports the standard OpenStack APIs you can present what looks like one cloud here on users. So this is, let's see this is, oh it's way at the end now. So let me, oh I've ruined the surprise. Hopefully nobody noticed. All right. Okay so this is just an example of a user logging into the VIO portal which is standard horizon. We don't modify or tweak any of this. The value to our customers is that they get standard OpenStack APIs for their developers. You can see that, you know, I look I've got one hypervisals that means I've got one vCenter cluster with 32 vCPUs running. And a couple of them are used and it's got a bunch of RAM. I can go over and I can show you a set of instances that are spun up. This is all standard VMware integrated OpenStack exactly what you'd expect out of the box. The interesting thing happens next. So what we're gonna show now actually is the ability to go up to the top and actually select another region. And this region doesn't have to be VMware infrastructure at all. In fact this is a region that includes KVM infrastructure. But I can still be logged in as the same user and using the same portal, the same tools, the same APIs. And here we can see I've got an instance spun up. It's a KVM instance and it's spun up on an Ubuntu hypervisor. So again this is the point that some people say, well oh well if I use VIO then I can, it makes sense it seems like the right way to start but what happens if I wanna use KVM down the road? So that's why we wanted to show this example. If your solution is vigilant about adhering to standard OpenStack APIs, then the interoperability like this is trivial. And so that's fundamentally the commitment VMware makes to its customers. Is that we're gonna expose OpenStack on best of breed VMware infrastructure. We're gonna expose those standard OpenStack APIs. All right well again thanks for your time. If anyone has any questions afterward feel free to come up.


Put this put this up here. Okay, everyone. So publishing two videos today This is the second one talking about Nike So this is not a vlog This is me talking and sharing my thoughts on what has happened and transpired over the past I guess it's been probably about three or four weeks now and for those that don't know a New York Times article was released I'm gonna say early November. Sorry. I don't know the exact date, but early November and it was an interview with a great runner Mary Cain and Mary Used to run under a coach Alberto Salazar who was a coach for the Nike Oregon project up in Oregon in I guess it'd be in the Portland area and The article outlined Basically some very Serious allegations about Alberto Salazar and the culture of the Nike Oregon project basically shaming Ladies and Mary about their weight and about how they need to lose weight in order to compete Better in running and I'm summarizing very very simply, but So this article is posted. It's the New York Times So it's a really big deal and a really caught hold I would say outside of the running world as well like people who have nothing to do with running and don't really You know care about the sport of running. We're talking about this article So the reason it's taken me now it's what late well heading toward late November It's taken me a while to bring up the topic. First of all I was in Argentina representing the United States at the world mountain running championships And yes, the USA USA track and field is their I guess main sponsor is Nike So there's the Nike swoosh. So I was busy and then also I was finishing a book Called shoe dog probably some of you have read it It's about the founding story and yeah the founding story of Nike It's the memoir of Phil Knight who is the yeah, he was the founder of Nike Along with eventually Bill Bowerman a former coach at the University of Oregon So I was finishing that book and I wanted to finish the book so I could really fully grasp the story of Nike So the timing was really interesting the dropping of the New York Times article and literally I think two days later I finished shoe dog the book and then lastly I've learned over time not to put my thoughts out on the internet and like immediately like People like social media is just so aggressive And I like to let a story kind of play out a little bit and sure enough as I was kind of researching everything on the flight To Argentina another article dropped by the Oregonian a paper in Oregon I think it was you know kind of giving Alberto's side of the story Alberto Salazar side of the story and for those that Don't know Alberto Salazar Very successful marathon runner back in the 70s won the New York City Marathon three times in a row and Really? Yeah, so he's a very accomplished runner back in the day Okay, so I must say the book shoe dog did Open up a lot of layers behind Nike and behind the founding of Nike behind Phil Knight It appeared to me to be a pretty fair assessment of the struggles that Phil Knight went through and also kind of the aggressive nature of Nike as they grew and grew and grew in the really in the well Yeah, really in the 70s and 80s especially late 70s and 80s and you know Nike's come out of come under a lot of fire in the past, you know even in this book Phil Knight's memoir He brings up. I don't know if you remember like the sweat shops I guess in China that were just really bad working conditions that Nike was making their shoes in This was don't quote me, but I think this was like early 2000s. It kind of came to the light and Overall, I think the book was pretty fair. It was just pretty fair. Oh, and you know, I'm an outsider looking in but it gave me a decent respect. I'll just put it that way for Nike You know, no one's perfect. No, no, no company is perfect Of course, you know, usually if you're at the top of the mountain, everyone's gunning for you So Nike's at the top as far as revenue. I think Adidas is second Like, you know, just in terms of dollars and cents like they're the biggest shoe company in the world I still think Michael Jordan's influence on the company will forever cement Nike at the top for a long long time So Then all this news begins to break about Mary Kane and the Nike Oregon project Which is a training group up in Oregon For elite runners who are trying to make their career As professional runners whether it's on the track whether it's on the roads Galen Rupp is a name. Of course that everyone knows Cara Goucher Used to run up there. A lot of great runners have gone through the Nike Oregon project Amy Yoder Bagley is another name that's come up in this whole situation and So from what I and I guess also yeah, so I have a couple names written down here I've got Mary Kane Cara Goucher and then kind of a third one that would not and I don't know this story as well But that would have not have been Would not have been connected to I'm sorry to Alberto because she's a sprinter, but Alice in Felix. So Alice in is I what I mean, she's got to be the right the best. I would say the best us sprinter of all time, you know I don't know how you could argue against that. She's just she's been crushing it for a decade plus She's just been amazing.   And so Alice in Felix left Nike and now she runs for Athleta and any I don't know know something. I'll put it on the screen right now. I anyway and She's trying to qualify for the Tokyo Olympics 2020. I hope she gets it. So so bad I hope she got rooting for Alice in Felix. She's 33. So she's a year younger. She I think she's 33 bottom line is What happened under Alberto Salazar is also a bunch of you know, what and Makes me very upset and the fact that Cara goucher a former Buffalo and I'm looking at my screen here because I'm looking at my notes She's she's come out very vocally in and listen Cara and Alberto Were like this so Cara's father was killed by a drunk driver when she was a kid and from what I could tell again outside are looking in Alberta was a little bit of a father figure to Cara and So I think this has been really really hard for Cara who was also Her weight became an issue for the Nike Oregon project and Alberto and so it's just ridiculous and Here's where I'm struggling is this systemic Within Nike. All right, meaning is this go beyond Alberto now now kind of I guess a bright light is Shalene Flanagan who just ended her elite marathon running career She won New York City last year and now she is a coach at the Bowerman track club Which is also a Nike affiliated training group up in the Portland area So she I think she's come out and I've read some of her stuff like she's like trying to change the culture of What's happening up there in Portland with these runners these elite runners who are chasing down dreams and So I hope a tide is turning through Shalene in the Bowerman track club and would also really tease me off You go to the Nike Oregon project comm website It doesn't even exist like so I'm just one like it's it's literally not there and so At least on my computer and so Mark Parker the CEO of Nike I Haven't seen any major Now, let me know down in the comments if I'm wrong. I haven't seen any major vocal stance about this situation With Alberto who is now also on leave for four years from coaching because of other issues. I'm not even gonna get into it and so bottom line I am Now the question becomes and I'm not afraid to go here Does this mean I won't wear Nike? I Will say this much so I'm obviously wearing something Nike right now. I've got Nike shoes right here I'll say this much if I don't hear some more vocal stance against what's happening like okay The US Olympic trials 2020 June see you in Eugene. Okay. I'm coming I I It's like it's at the it's at the University of Oregon Which is a Nike like everything at the University of Oregon is run by Nike on as far as buildings and new stadiums and everything There's gonna be protests if there's not a more vocal stance against whatever is happening up there now Maybe chelene plan again can be a voice in a light in the darkness But if Mark Parker and again, please help down in the comments Is he making a stance? So I am Now I will also just say one thing The dignity of the human person I truly believe in it even yes, I'll even say it Alberto Salazar We need to We need I believe every human being has dignity and I don't want to trash Alberto down in the comments I don't want to trash anybody I just want to make sure that there are healthy Relationships and healthy Training and healthy everything going on up there in Portland. And so I just want to make that point like I still believe in the dignity of the human person and it appears Nike that you've placed winning and money and Sponsorships maybe above the dignity of the human person in the past I don't know if it's gonna happen continuing moving forward But please Mark Parker if you're out there, just let us know like because at the end of the day, right? Everybody it stops with the CEO that buck starts. Yeah, how's that saying go the buck stops with him? Is that how you say it? It stops with the CEO So if somebody's got to speak up and I just haven't heard it yet again I've been traveling and I haven't really had a chance to read all the articles but that is my position that is my stance on the Nike situation and unfortunate situation I Hope that Wounds can be healed. I hope all three of those women Kara Alice and Mary and all the other women that were impacted by this Nike Oregon project Debacle can heal from it because I know it can be painful To talk about weight and to struggle with that and eating and oh my gosh, it gets really serious really quickly And now Kara goucher. She just ran the north face 50 mile. Yeah out in San Francisco. She's becoming an ultra runner It's amazing. Anyway, I'm very disappointed. I'm still gonna wear Nike I'll just I'm not afraid to say it, but I'll say this much. They're on watch with me on They need to be a little more something needs to change and obviously getting rid of the Nike Oregon project is a start if it's gone for good. I don't know and I again, hopefully Shalane and the Bowerman Track Club can Turn things around Love you guys. Thank you for listening. I know that was a little different a little bit of a rant and That is that so I'm sure I'm missing something I look forward to your thoughts down below and yes question of the day for this video is Share your opinion. Where do you stand? Where do you fall? Am I missing some information? I probably am I try to do as much research as possible. There's a lot of information out there That's that


Super Bowl, as it's called. It's next Sunday, not tomorrow, but the one after. They usually make it the whole, all the other teams are jealous and then all the conspiracy theories, blah, blah, blah. But the very good thing that I really like about this team is that they really function as a team. There are superstars in this team, like to take a soccer reference or the real football reference, there's like Messi and Ronaldo in that team. The quarterback is married to a supermodel, really fantastic players and very celebrity kind of people. But the great thing about them is that when they enter the stadium, they're announced as the New England Patriots. And they enter as a team, whereas the other teams, what they do is, here's Ronaldo, yay, here's Messi, yay, whatever. But for the NFL guy, I mean, for the Patriots, they all entered as a team. So these guys are entering the stadium as a team. They work as a team, they're solid. Why am I telling you all of this? Is because this slide deck is nothing, not much to do with me. I just took collaboration, collaborated effort from everybody. This is really a team effort, this whole slide deck. So if there's something wrong in it, I get to blame my team. And if so, you guys caught me. OK, team effort, lots of contributions from the team. Anything. So what to expect in this presentation? So I'm going to talk about what 99% of the universe needs. So by the way, the title is not clickbait. I do feel strongly about this title, and I'm going to talk about this also. So what 90% of the universe needs, what 75% of the universe needs, but doesn't care how it's done. And what we have to do, all of us, Linux, networking, whatever, to make it possible, that we don't want to know how it's done, but we still want it. OK, fine. Then we are going to do some boring stuff or the real technical stuff a little bit, because there are so many developers here. I don't want it to make just a fluff presentation, as they say. So we're going to talk about differences in some packages and actual technical information. And then I'll let you be the judge that, did we really need this new package or new protocol or new something, or is it more of the same or something?  And then lastly, coming back, wrapping up, I'll give you some things to think about.  Please feel free. I've seen my teenage children's rolling eyes, so I'm used to it. I won't be offended. I'm used to it. OK, so what 90% of the universe thinks it needs? I just want an external address to talk to the rest of the world, World Wide Web. And I need an internal address to be able to talk to containers or VMs or other things in my laptop. And easy peasy, just make that happen. All these blue waves in between, I don't care. I just want to be able to talk to the rest of the world, and I want to be able to talk to within my computer. That's it. Easy, fine. What they really mean, 75% of the people, what they really mean is that I want security. Yes, I don't want it to be hacked. I want privacy. Again, I don't want it to be hacked, et cetera. Multitenancy. Before I go on to these, so one of our board members, her name is Charlene Bagley. I'm sorry if I'm butchering it. She said something very interesting. We were in a meeting with her. She said that IT, I'm paraphrasing. This is not a direct quote. She said that IT is now discussed, IT networking, network security. All of that stuff is discussed at the big giant company's board level, like the board of directors level. It used to be pretty much, does my printer work? Is there a printer jam? Can I connect to Wi-Fi? Is the email working? Fine, if it isn't, if it is, great. But now it is talked at like board of directors level. She's also on the board of directors, I think, of NASDAQ and some other companies. So it is discussed at that level because it is such a big deal. Nobody wants to be hacked. Nobody wants to be in these problems. As you have seen the headlines, apparently the US elections were influenced because of hacking scandals, et cetera. So nobody wants their company data and private. So Red Hat is good that everything is open. But still we have financial data, internal communication, et cetera. We don't want somebody to take it. So security, privacy, multi-tenancy, fast. It has to be at least speed of light. If it's more than that, it's OK, but at least speed of light. Switching, routing, load balancing, fairness.  Like I take my laptop or I move somewhere else. No problems should happen. Fine. If the environment moves, things should stay up. Like if my IT guy changed the Wi-Fi or whatever, changed it to N instead of GE, I don't care. It should not get in my way at all. And it should have downtime, of course. And it should have zero packet loss, of course. And zero latency, which has to be speed of light, as I said. And it should be able to walk on water. Easy peasy, right? So this is a picture of a packet walking on water on speed of light, as you can see. But other than that, anything? No, that's OK. This is just, let's start with that. That's what they need. So what we have to do to make all of this stuff a reality. So we have to make it easy config, right? Config, if it's hard. If you have to open a command line these days, it's a no-go. Tunnels, we have to create bridges, bonds, namespaces, all of the stuff that, again, you are now saying, I don't care about. But seriously, we have to take care of all of this all the time. OK. So now, before I change topics, I just give you a perspective from what people perceive they need, what they really need, what we have to do about it. And now I'm going to switch gears a little bit and talk about the different packages, different protocols, different setups that we have available and why they are available. Now coming back to the theme of this thing, while you are going through, I'm going to go through a set of slides to show different packages and what the differences are. For example, network manager, et cetera. As you are viewing this, a couple of things I want to note, because I'm going to forget before I start. I'm going to reference at the bottom. This is just like a snippet of the differences and information. There is tons more information available, and there's going to be a link at the bottom. I'm going to make the slides available, of course. And you can click that and get tons of more information about it. And the other thing is, as I'm going through this, I want you to just think about it, that are these packages mostly the same, another slant to the same thing? Or it really is very different? And yes, there was a need for it, and we really needed it. So I'm not going to be the judge of that. I'll let you be the judge of that. Let's go through them, instead of just talking about it. So configuration and management, we have three choices. One is network manager, of course. It does everything in the kitchen sink, and it does it very well. And for those people who weren't here in the first two minutes, we have nice network manager stickers. Please feel free to take one. Of course, when there is a sticker, the project is real. So after 13 years, network manager is real, because we have our sticker. So it takes you out of the Wi-Fi, Bluetooth, everything. Again, the environment changes. It scans the Wi-Fi as you leave, et cetera. It's extensible. It has D-Bus interfaces. It's the same, and the good thing is that a lot of, even I didn't realize it until recently, is that it is in Fedora. It's in Rel, of course. It's in Ubuntu, Debian, and even small devices like Raspberry Pi. So it's used very extensively. Sorry, wrong direction. And then we have comparatively network D. Again, very important. It is minimal, small footprint, does a lot of good things. It comes with D-Bus API control, tiny, as I said, lightning fast, used in container land a lot. Doesn't do all the Bluetooth and Wi-Fi, but for very good reasons. So that's network D. So network manager versus network D. As I said, I'll let you decide. And then, oh, stickers. Here's the sticker again. And then IP route. That's the third one. Third config manager. Again, this one is more suited for kernel hackers, et cetera, a lot of work that you have to do. The fully manual configuration, it does not remember state. So you have to take care of all of that yourself. Some drawbacks, some good stuff, but a lot of people love it and like it, especially for kernel hacking and where you just want it to work. You know what you're doing. You just want to set it up and you have a script that you want to do on top of it. OK, so that was configuration management. Let's move on. Oh, there's an example for IP route. Again, as I said, there is more information. I have links on all my slides where you can get more information. So let's compare Libre Swan with open VPN. First of all, anybody who's a Red Hat employee, your VPN will continue to work on April 1st. If you don't know what I'm talking about, that's a good thing. So they're changing the corporate VPN, et cetera. I talk to the NM guys. Don't worry about it. Everything is fine. It should work. No worries. Famous last words. My team members, please don't make me eat these words on April 1st when the switch is. But open VPN versus Libre Swan, many differences. I'm not going to go over the whole alphabet soup, et cetera, about it. Some similarities, some differences, very important. But you can get more information as you want at the bottom I've placed it. IP tables, firewalls are super, super important. We have been familiar with IP tables for a very, very long time. They are used extensively. There were some drawbacks in IP tables that got filled by NF tables. For example, there had to be different config and different setup for IPv4 and IPv6. Whereas NF tables, it's all combined, one and the same thing. So combined, iNet family can be used for both IPv4 and IPv6, which is great. For container space, it's good. There is not a happy migration that you can do from IP tables to NF tables. We are still measuring some performance differences or performance benefits. It seems like NF tables might be faster. It is 90% feature-comparable, feature compatibility, or feature-complete as compared to IP tables. And for the remaining, 10% work is in progress. OK. Moving along. Whoops. Security, MacSEC versus IPSEC. I don't want to make anybody. IPSEC, well-known, well-established, been there for a long, long time. And the choice really is, if you want to do L3 security versus L2 security. And then we have MacSEC. And before I forget, Sabrina had a talk last year on it. And she also has another one this year at 1 o'clock, very soon, in the same room. So if you are interested in learning more about MacSEC, please stay back or come back at 1 and you'll know more about it. But IPSEC and MacSEC, these are two different approaches. They provide encryption, as you know, for packet encryption, back and forth. And I'm already boring you with all the details. But for some use cases in the cloud, layer 2 might make sense. For other use cases, layer 3 might make sense, especially for control plane. It depends on how you set it up. So these are very important things to consider when cloud deployment. And people are asking us for both. Bonding versus teaming. Jerry Percot is here. Jerry, I left the slide in there for you. So again, many differences and similarities. The biggest difference between bonding and teaming is that bonding, everything is in the kernel space. Team driver, the control plane, or the setup and management is in user space. Performance is one and the same. It's pretty easy to set up, et cetera, et cetera. Overall, it's good. I'm doing OK on time, which is good. Time sync, NTP versus PTP. NTP, again, been there forever. Everybody uses it when you turn your computer on, laptop, whatever. It gets the time through NTP. And then that wasn't enough for many use cases, especially for high frequency trading guys, et cetera, to time sync the, I don't know, Moscow stock exchange versus New York's exchange, versus the Shanghai stock exchange. You have to make sub-nano second decisions on stuff. We have all seen the glitches where $2 billion were lost because of this, because of somebody hitting fat fingering, some stuff. So there's a lot of money at stake and time, of course, is of the essence. So PTP provides a lot more granular time-based syncing. It comes with GPS sync. It comes with much more precise nature. So for things like, I just gave an example, like for Hydron Collider, for military uses, for ultra-frequency trading, as I mentioned, PTP is your friend. Of course, it needs some special hardware. It doesn't come for free. But it is essential for some use cases. Millisecond versus maybe picosecond, but definitely sub-nano second. But it can be as precise as a picosecond. OK, so tunnels. So why do we need tunnels? This might be like, what, Rajan? So tunnels we need for host-to-host communication.  That's no longer enough, right?  All well and good, but many choices, as usual. So there is VXLAN, well-established at this point. A lot of Silicon vendors have VXLAN offload cards. So you might be wondering, why is there a problem? We have had VLANs forever. So here's a question to anybody. Why is VLANs not enough? Why did we ever need VXLANs? Yes, somebody said because of the 4K limit. Yes, VLANs come with a 4K limit. And it is quite conceivable that in a cluster, 4K is not enough at all, virtual machines, 4K containers. That's chump change, right? It's like I have more cluster, more virtual machines in my basement than 4K. So you needed more. So VXLAN was available. VXLAN was pretty much a drive because of that. And then it didn't have, it's pretty good. It does the job. It is part of our solutions for OpenShift and OpenStack used extensively, as I said, hardware offload cards. And then the new protocol that's coming up, which is used with OVN, especially, is Ginev. It's developed by some of the original guys from Nigeria. It's pretty flexible. It is more future-looking. It has an extendable header. It comes with support for future stuff like NSH and service function chaining. So it is more future-looking and advanced. But the drawback is not many hardware offload cards. There's customer entrenchment, et cetera. More information at the bottom. Then we are also working on Q&Q, which solves the VLAN problem, much, much lightweight than VXLAN. 2 to the power 12. So the 4096 problem is gone now or can be gone. Eric Garver, who has a talk not on this subject particularly, but he has a talk later on on CPU utilization, I think. Something to that effect, I forget. But if you are interested in Q&Q and what has been done or what he is doing, feel free to please talk to him. He's going to be around this afternoon. What else? Oh, yeah, NVGRE. So NVGRE is also used a lot in data centers, particularly Microsoft-centric data centers or Microsoft site of families. We do support it. Again, many drawbacks and good stuff in there. OK, now we are getting to the interesting parts or at least more interesting to me parts. So we had OpenVSwitch for the longest time, part of our products. It is being used. So what is VXLAN? It's switching between hosts. So it is like if you have many virtual machines, you need to switch between them. Have the same package goes in, that goes out, has learned. And then it repeats. It learns and repeats and flows based as DN connections all the way to ODL. All thumbs up, very nicely done. We are working on OVS offload, hardware offload cards now. It's so mature that people are investing and putting out silicon and cards, which can do OVS offload. Huge success based part of OpenShift, our container solution, part of OpenStack, our VM solution, and also going to be part of Rev, which is also another VM solution. So really nicely done. All thumbs up. We have in-house expertise, plus very nice work with VMware, et cetera. Lots of collaboration with them. Another good thing about OpenVSwitch is that it was originally designed for kernel data path. We'll talk about what the differences are. It holds that thought. It was originally designed for kernel data path, but works very nicely for DPDK data path also. And now the new thing that's coming up is VPP. VPP is developed by Cisco. Very different design. All user space, all dependent only on DPDK. It sort of can work with kernel data path, but it's not designed for kernel data path. It is designed for working with DPDK. All the packets go to user space and then switch from there. It is gaining some traction. We are evaluating it. We are looking at it. There is competing information. Now people are doing comparisons. Some of our partners, huge partners, are saying OVS plus DPDK is enough. We have measured it. It's faster than VPP. And then some of our other huge partners are saying no, no, no. For some applications, you need VPP. You really, really need it, not even want it. But the jury is still out. As is the usual case with Red Hat, we want to remain partner neutral and vendor neutral. So we are evaluating it. We are thinking about it. We are investing in it. What happens is that we have to invest a lot in these packages. It's not just enough to download it from upstream for making them part of RHEL and especially our cloud offerings. We have to do a lot of work to harden them, test them, get them to a point where, as Denise said in the earlier session, that we have to take the call at 3 AM. And for that, we have to harden them, test them, et cetera. So we are looking at it and trying to see how much investment we need to do in there. So these are two competing standard switches, switching standards at this point. The jury is still out. Which one is better? Please ask me again in a year or sooner. How many people attended my session last year? I could have gotten away with it. So these are slides now from my last year's talk. So as you see, the background is different. I copied-pasted from there. But there are some people, so I have to fess up. I pretty much copied them from last year's talk and stuff. So this is a good illustration that shows the differences between KernelDataPath and DPTKDataPath. There was a talk yesterday that talked a little bit about that also, but this gives a visual representation of the same thing. So packets have been traditionally going through the KernelDataPath forever, from outside world into the Nickdriver, into the KernelNetworking. And then it crosses the boundary, goes to user, open vswitch through the vhost net QEMU, goes to different virtual machines. Easy peasy, no problem. But then it was conceived that it's not fast enough and it's very difficult to work with the kernel guys. We need something faster, we need more control, et cetera, et cetera, for very good reasons also. I can make arguments both ways. Some packets go directly to the PMD driver into DPDK and then onwards in the middle diagram. And that's pretty cool too, no problems with that. It does give all the control in user space. No issues. But this problem might be that then you need everything in user space, okay? What does that mean? Hey, what about TCP? Yeah, now you need TCP in user space. What about vxlan? Oh yeah, now you need vxlan in user space.  So the stack in user space is being created. Some people might call it redundant, might not be. For NFV kinds of applications, DPDK does make a lot of sense. DPDK also makes sense inside the virtual machine. But for many use cases, for traditional customers, like banks, et cetera, it might just make sense for remaining on the kernel data path. But the third one, the rightmost column is device assignment, also known as SRIOV. This is direct connect, you know, like you'd get the packet memory sharing, et cetera, directly into virtual machines, no kernel, no DPDK. And most of the people who need real-time applications, high, low latency, et cetera, let's say telcos, they are still on SRIOV and the device assignment. What they are asking for is to be able to move or easy migration path from device assignment into OVS LAN, into DPDK LAN. As you can see in the right diagram, our rightmost diagram, there is no switching. So it's direct connect into VMs. So it might mean that if you have to go from VM to VM, you have to go back out the box into the top of the rack switch and then come back. So there is latency involved in going to VM to VM. More information about all the three diagrams and some of the stuff that I blabbered about in here, pros and cons. There were some items which were work in progress last year, I'm happy to tell you that they're all done or mostly done, 99% done. When I say done, I don't have any PM requirements at this point for the major items. They are requesting some stuff, but there were some showstoppers or must-haves last year when I presented this, but now most of the must-haves are being done and now it's just improve it, make it better, make it more stable, which we are working on. XDP, I requested a bulletproof jacket, but the budget wasn't there. So I'm gonna skip that for now. Let's talk more about XDP next year or in six months. The jury's still out, it's a new concept. I just wanted to show the seed that yes, there is another alternative that is being worked on. Please look it up online. We'll talk more in about six months. Okay, I think I'm doing okay on time. That's good. So I talked a little bit, I had to balance this talk, as you can see, some fluff stuff in the beginning, some fluff stuff in the end, and in the middle I gave enough technical details and I rushed through them because I didn't wanna bore you with like NVGRE and what is the third bite of the third syllable, et cetera, et cetera. But for technical guys who actually are interested in finding out the differences and are interested in making the choice, like should I use GRE, should I use Geneve, should I use VXLAN? I've provided some summary information in my slide deck and I provided a link at the bottom where if you click it, there's tons and tons of more information. I apologize in advance that I could not make them public public, but I promise I will make all those links public for the non-Red Hat people in the room or people who are going to see this later on. I will make completely public links available. Right now they are public or they are open to all Red Hat employees, but as soon as I go back, I will blog. Some of them we create, some of the write-ups are so nice that we can blog them as is. So we will just blog them and I'll replace the links in my slide deck or send an update about it. But if I can't blog them, I will try to make a Google Doc or something which is visible upstream. So point is that for the Red Hat employees, all the links should work. For non-Red Hat employees, I will make them public within a week or so, hopefully. So now I'm gonna switch gears a little bit back and this is now something to think about, something to evaluate and I just want to throw it out there. I think it's important to me. This is the part of the presentation where you can get ready to roll your eyes. Okay. Now the bullets are coming from the top. Did you notice that? Switching gears, get it? From the bottom, now the top, no? Nobody noticed, that's okay. So what is happening is that others are now trying to disrupt us. I was talking to Werner Noblek, he's one of the very high-up sales guys. I think he is in charge of all sales outside North America. Very smart guy, I talked to him on Monday. He said very interesting thing that I had never thought about it. He says, Rashid, the open-source game and the Red Hat game and all of that has been done there, been there, done that, established, et cetera. We open-source guys and we Red Hat guys were trying to disrupt the industry and trying to disrupt the status quo. We have done that, we have succeeded that, we disrupted us. We have done it such a nice job that now other companies that you know better than me are trying to disrupt us or trying to disrupt the open-source philosophy or trying to disrupt the Red Hat philosophy. So we, sorry about that, I don't wanna make somebody blind with my laser pointer. So what is happening is that we can't slack off. You know, now that we are established and earlier KB was saying now that we are established, people are relying on us, people are depending on us.  No, no, no, that's been there, it's old news. Now we really need to CI CD this stuff. We have to make it work. It has to be stable, it has to be guaranteed. Like really guaranteed to make it work. Imagine if you're some relatives BP measuring machine, I'm just taking a blood pressure example, but it can be more complicated than that. In IoT devices, if the healthcare industry starts using Linux and you don't want your BP measuring machine or even more critical path than that to stop working because there was an update somewhere, right? So for IoT devices, for your self-driving cars and other stuff, things are getting very, very critical path. So we have to be careful about this. The other thing my request is for all the developers and kernel hackers and everybody, there is life outside the mailing list. Yes, there is. Absolutely, I've been there on both sides. So, inventing something new, inventing patches accepted upstream is now just the beginning. Think about it for a second, seriously. What used to be is like I have patches, I'm going to work very hard, I'm going to talk to people, I'm going to solicit their opinion, I'm going to send an RFC, I'm going to get patches accepted upstream, I'm going to send patches, I'm going to get people's feedback, I'm going to work on all that feedback and yay, my patches got accepted, applied, David Miller, thanks. So all that email came awesome, but that is now just the beginning. What do I mean by that? There's an ecosystem that we have to worry about. Your patches, if there are new patches or a new thing that you invented got introduced, then we have to think about, okay, how does it fit into the giant ecosystem? I'm not talking about the business side of things. This is not a business conference, this is not a marketing conference, so I'm not talking about that, please don't get me wrong. I'm really talking about the technical aspect of this. I don't want to give an example to offend someone, but I might offend someone, so I'm thinking of, let's say you invented, you invented an eraser, right? So 90% of the world, oh, I have a prop stuck in mine. Let's imagine this is a pencil. 99 of the world's pencils look like this. Let's say you invent an eraser which is square, fine. You needed a square eraser, awesome. You have very good reasons to invent a square eraser. What you have to think about is, how will it fit on the 99% of the world's pencils? So there's an ecosystem that we have to worry about. If you invent something new, that's fine. If 99% of our customers and consumers are using the round pencil, great. Your square eraser is awesome, but how does it fit on a round pencil? So we need to think about the ecosystem. How does it package? How does it get released? All of that stuff.  I'm not saying we should stop innovating, but then after the patches are accepted, we have to do some advertising. Again, outside the mailing list. There are seven billion people in the world, right? Most of them are not on mailing lists. It might be a surprise to some people, what? No, yes, most of them are not on mailing list. So it's not enough to say, just look at the patches and how it works, great, it's awesome. Your patches are awesome, no doubt about it. But we have to advertise it off to the people who are going to use it, consumers. Again, not talking about customers. Okay, let's talk about it a little bit more. I think another bullet will come. So another reason that people in the past have been putting out something new, brand new, instead of using more or enhancing the same is that there is a glory aspect associated with a maintainer. Yes, there is, no doubt about it. I invent a square eraser. I'm the maintainer of the square eraser. And then from there on, there is a glory aspect to it. But in my opinion, there is just as much glory as a maintainer as a contributor. So if you take the round pencil and you contribute towards making that round pencil better, I think there is just as much glory.  And then there are people like me saying, have you done, don't worry about the maintainers. So you have to think about that as well. So bottom line of this slide is that getting the patches accepted upstream for something brand new that you might have invented is just the beginning. There's a lot more. We have to think about the ecosystem. We have to think about the advertisement. We have to think about the integration into the upper layers. And that is super important as well. So something to ponder for future development. And this is, believe me, I'm not preaching just to my team. So please guys, my team members don't think that I'm just right. I made this slide of the last two slides for you. It's really for the Linux community at large, everybody. Some things to ponder for future development. So enhance versus redo versus reinvent. I gave an example. Should I enhance the round pencil or should I invent a new pencil or should I invent a new eraser? Something to think about. In some cases, it might make sense. The examples that I gave of some packages, it absolutely makes sense to invent something new. The last one was not enough. But in some cases, it didn't really make sense to have something new. Did it? Maybe. We have to think about our customers and consumers. Thank you. I have 15 minutes left, which is good. I'm almost done. We have to think about our customers and consumers. Again, please don't get me wrong. I'm not talking about our customers. Oh, Rashid, you are telling us to worry about the paying customers only. What about the free guy? What about the chemistry lab in Kathmandu? Yes, absolutely. I have to worry about the developer or the poor master's thesis guy in Kathmandu University as well. But he's your consumer. For me, honestly, the big giant IBMs of the world are just as much of a customer of mine as they are the one master's thesis guy in Kathmandu University or whichever university. So the consumer and customer matter also. Existing entrenchment matters. Coming back to the pencil, right? We have to think about what is already happening. Please participate in RFC. So if you see an RFC around your area and somebody trying to say, hey, I'm gonna invent something new, awesome, please participate in that. Please give feedback and say, have you thought about it? So that if there are corner conditions or if the guy is trying to paint himself in a corner and not flexible for long term, you can point that out saying, this header, you've only put 32 bits. What about 64 bits? What about future considerations? Please give that feedback. It shouldn't be like, oh, I don't care. It's not one of my business, 32 is fine. It works, that's it. No. Then later on somebody will invent something new which takes the 64-bit header. Maybe we should have avoided that. Suggest flexibility for future. I already talked about it. Be a rock star. So credit to Tim. How many people attended Tim's keynote last year? Cool. So Tim sitting here, I didn't know he was gonna be here. But to give him credit, he had a good presentation last year. You can look it up. He said, be a rock star. So trademark Tim Burke from last year's conference. So he said, be a rock star. Be a contributor. Be a contributor. Be an enforcer, positive influence.  And this is sort of part of that. Oh, my package. I'm gonna invent something new anyways and I'm gonna not. So be a rock star. Please look at his presentation. I think it gave a lot of thought, good things to think about. Get feedback before doing patches. So all of us doesn't matter. Red Hat, non-Red Hat. We have people who take our code and make that useful. And these people are TAMs, technical account managers, solution architects, GSS, all of these people. They're going to take our code and patches and then make it useful. They are in the trenches every day. They are the people who get yelled at. They're the people who have to say, you have to encrypt every bit and then they have to go and answer, why don't you have to encrypt every bit? Or what is the drawback of encrypting every bit? These are the guys who have to make it real. These are the guys who have to make our solutions acceptable. So are we solving the problems that they are seeing or are we solving the problems that we are seeing? It wouldn't be great if we solve the problems that we both of us are seeing or at least solving the problems of our customers. So let's solicit information or ideas or feedback from solution architects and GSS and TAMs. Again, contributor can share as much glory as the maintainer. That's it. So I did want to intentionally leave a lot of time for questions. I can go back to the technical slides if you want and answer your questions or there are enough people who are much, much smarter than me in the room who can answer your questions in details but questions, comments, yelling, Advil, coffee, all welcome, come on. Okay, for the first question there's an extra party ticket. It has to be a good question, yes. Excellent question, excellent question, excellent question. Why is there an octopus? So the network manager is trying, if you look closely, it's taking care of a laptop, a server, a phone, ethernet cable and it's wearing a Bluetooth in the ear. So network manager is managing or taking care of or controlling all these devices. So we needed a graphical cartoonish representation of that and this is what came out of it. Your party ticket is with me. Please feel free, come down. Anything else? So yes, yes, please. Yes, so a very good question. Network manager guys who are sitting here, please correct me if I say something incorrect. Repeat the question. Yes, yes. The first question was in the back was why does the network manager sticker have an octopus? And I think I answered that. The next question is on small devices are there contentions on resources, footprint, RAM, et cetera, et cetera. Very good thing about DEF CONFIS that the hallway track and the track come in the tram interactions and the party interactions are awesome. That's why I come here every year. That the most important track is the hallway track as they say. Two years ago or three years ago, I was just in the tram with Matthew Miller. Just happened to be here. I didn't even know the guy. And he says, Rashid, everything is awesome with network manager, but it just stays on forever.  There's a term for it, config and quit. Config and quit and make it smaller. So what we did was we worked on it and what we did was we made it modular and a la carte.  And earlier on, it was bringing on the Bluetooth and everything all in one. Servers don't have Bluetooth, so you can shut off the Bluetooth. Summarizing the answer. It is much more modular now. It really can be a tiny footprint.  And if you have more questions, there are network manager guys who will be more than welcome to answer it. But a short answer to the long thing is much more modular. We haven't seen any complaints about it recently about it being too fat, I can't use it. As you see, Raspberry Pi is using it. Sum. Is it going to be running in it RAM FS? Okay. Good point. I will consider that for as a future enhancement. And I mean it, seriously, I mean it. This is the kind of stuff that I come here to get feedback on, on all the worst stuff that we work on and we incorporate it. And this sticker is a proof of that. As I said, this came at DevCon, this idea came last year. Anything else? Yes, sir. You guys ask a couple of things. So let me just first say, DPDK is supported by Red Hat, full-time. We have people dedicated to it. We have resources assigned to it. We are hardening it. We are contributing it upstream. We are full-fledged behind it. We are full-fledged supporting DPDK. For OpenVswitch, for inside the VMs and on the host. It's part of our solution, supported solution. Then you ask, is it Linux, not Linux? Yes, it is. Some people, I can argue both ways, but I can argue easily it's not Linux. But we do support it. It is accepted upstream. There is no fork of the code anymore. We collaborate with the Intel's of the world and the six wins of the world, and we supply patches. We provide feedback on patches. We are trying to enhance it, optimize it. Networking team is working on it. Virtualization team is working on it. There are people dedicated upstream on it. So yes. Yes, sir. In the back, my partner in crime. The question is, are there, summary of the question is, are there plans for long-term support or long, LTS, excuse me, LTS release of OBS? Yes, absolutely. There are upstream, from right from upstream, Nigeria, VMware, there are now LTS releases. So we always were waiting for that. We helped them establish that. We helped with the testing. Now they have LTS releases of OBS. Great. We will support them. We will latch on to them. We will have to work with the PMs, et cetera, to make them part of our products, whichever. But the specific example that you're talking about to go from one to another, it wasn't really about LTS. It was more about our understanding on how OBS, did I do something? We learned a lot from that experience and we are going to make sure that it doesn't happen. So we did, it was a good learning exercise. I know it causes some problems, but we learned a lot from it and we are going to make sure that the startup, it was a change in startup to fix a bug. But we learned a lot from it and we'll make sure that it doesn't happen. Or try as much as we can. Hopefully it doesn't happen. How are we doing on time? Okay, last question. I don't have any prizes to give. But seriously, please take a postcard. But there are other sessions about networking back to back almost. Feel free to come back or stay. There's good power, there's good Wi-Fi in this room. There's coffee outside. Okay, thank you very much.


The Hanbera State Governor, Charles Toludo, has signed the 2024 Appropriation Bill into law. Recall that on November 21, 2023, Governor Toludo presented a budget proposal of 410,132,225 for the 2024 fiscal year to the State House of Assembly. The budget, which is 57.8 percent higher than that of the 2023 budget, is focused on infrastructure development, education and health care. Performing the function, Governor Toludo thanked all stakeholders who have been involved in the entire process, pointing out that Hanbera State House of Assembly worked very hard to see that the law meets the needs and aspirations of India and Amra. The Governor revealed that with the budget in hand, the real transformation of the state using the five pillars of his administration will now begin. He noted that infrastructure and human capital are among the front burners of the budget plan. That encompasses the five pillars of our transformation agenda, whether it is the area of law, security, law and order, the issue of infrastructure and economic transformation, the human capital and social agenda, the governance and the new value system, and of course the environment. It was a planned, clean, green, planned and sustainable, and Amra, all of the budget pays attention to these five pillars, and we are starting, we are kicking on all. And several of them have already started. I mean, we have already started by the number. We are only changing gears, we are a gastro, all of them, all of them. There's no sequencing, not either this or this or this, before this. We are kicking on all cylinders, firing from all cylinders simultaneously, because Amra cannot wait. Amra cannot wait. We have a timeline, we have an agenda with a deadline, and so no minute will do. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel, and don't forget to hit the notification button so you get notified about fresh news updates.


your favorite song on death row records? Probably New York, New York corrupt. That nigga was so barred up on that and just to know how that song was created. See what y'all don't know is, that song was a St. I's commercial that Biggie Smalls had.  It's only a commercial. So we had Biggie, he was like, he ain't tripping. So we took the beat and I was gonna rap on it. But I was like, I don't know what to rap about. So I just put the hook on there. New York, New York, cause it's an old grandmaster flash song. And I'm like, I only helped him with one line. It's gonna take a miracle like Nisi. Like Nisi, he thought it was somebody else. He said it was somebody else. I said, no, that's Nisi. And he said, okay, like Nisi, it's gonna take a miracle.