 All right. Good morning, everybody. Thank you very much for coming. Thursday at the Metaca Summit, nearly there. Yesterday was hump day. Everybody know what I mean by hump day? Yes. Good, good. All right. So, happy post-hump day. I want to kick things off today with an overview of the extraordinary things that are coming in 1604 LTS and some of the great work that's been done in the last six months. Various canonical folks have presented here at the summit, so you may have seen aspects of this work presented in the normal conference track, but I want to try and give you an overview of how all of those pieces fit together. And the theme for our track day today is OpenStack for everyone. For OpenStack to be successful, it has to go from being a very exclusive, very specialist cluster of technologies into something that everybody assumes they can run for themselves. And critically, it has to come at no extra head count, no consultants, no special skills, no extra costs. If you think about it, for an organization today, for any organization today, they have the straightforward choice between public cloud and private cloud. And the driving force in that choice over time is going to be economics. And so it is critical to the success of OpenStack that we're able to compress those economics to make OpenStack comparable and competitive to the public cloud. Now, we believe this is easily possible. We believe that when done right, buying a hardware yourself using an OpenStack product which is focused on operations, focused on economics, and buying standard support for your infrastructure will cost less than using public cloud infrastructure. And that means that it becomes a genuine choice. There will be reasons for people to go public. There will be reasons for people to stay private. We believe that most will operate in a hybrid world. And what we're focused on is making sure that OpenStack makes the private portion of that hybrid cloud world both possible, but also rational, sensible, and inevitable. So OpenStack for everyone. Every six months, the OpenStack Foundation does a survey of OpenStack users. In this last cycle, they doubled the number of people surveyed, so 1500 participants in the survey. Increasingly, this has to be seen as a deeply credible, rounded view of what people are actually doing with OpenStack. And it makes fascinating reading in terms of the various parts of the OpenStack project which are being adopted, the various ways in which people are using OpenStack. And from our perspective, the platform choices that people are making with OpenStack. And in that very recent data, if you look at the share that is running on Ubuntu, the share of production OpenStack that is running on Ubuntu, it has increased globally to a majority of all OpenStack deployments, both for production and for POC DevTest. But for us, the most meaningful indicator is the slice of the data which looks at the very largest OpenStack clouds. And it's increasingly clear that big OpenStack deployments are on Ubuntu. And that, I hope, is a consequence of our relentless focus on the combination of scale of OpenStack, resilience of OpenStack, the operability of OpenStack, and the economics of OpenStack at scale. So economics are as important as technology. The technology that's happening at this conference is awesome. And I think OpenStack has succeeded in attracting this incredible pool of talent. It is slowly improving in its ability to harness that talent to deliver great results. The changes that we've seen to bring more focus to the core of OpenStack are, in our view, extremely important. To allow people to play with ideas outside of that core is great. But to signal very strongly to operators, users, adopters that there is, in fact, a commitment to a strong infrastructure as a service core is extremely important and will help with the progress of technology in that. Although we do continue to see the sort of OpenStack mumbo jumbo of confusion at the edges, the core is now coming much clearer and much more into focus. So technology in OpenStack is not something that I worry about. What I worry about is the usability and the economics of that whole. And what we see at institutions still is that they believe they need to go and hire more people and find unicorns, people who know everything about everything inside this complex world of OpenStack, right? And so our mission is effectively to say that's, you know, the unicorns are important, but we need to open the doors to OpenStack for everybody who can't afford or can't find that very precious talent that knows everything about everything in OpenStack. So that's why we focused on tooling that enables people to build the OpenStack themselves very, very easily. And more recently, a layer on top of that, which is in fact a complete autopilot, a complete top-to-bottom best practice management system for OpenStack, and that is the canonical OpenStack autopilot, which I'm delighted to say will shift from beta to generally available on the 10th of November, so in two weeks' time. Now this is a product that brings together everything we have learned across very large, very small, and very interesting OpenStack deployments. We are privileged to be in the middle of some of the very largest OpenStack deployments, OpenStack deployments where you have priorities in the networking, those we have priorities in performance, those we have priorities in economics, those we have performance, priorities in scale, those we have priorities in mixing different hypervisors, where you have priorities in experimentation with compressing the cloud down to the smallest possible size, clouds where the priority is the exact opposite, where you want the largest possible cloud. And we're able to take all of that insight and distill it not into consulting expertise. We do do that, but distill it into code that anybody can use. And so that is the autopilot. And the zen of the autopilot is simply that you should point at a rack or five racks or 50 racks of the hardware of your choice and build an OpenStack. So I want to show you how that has progressed. This is the current trunk of that Autopilot code. So we've removed the beta tag from the OpenStack tab at the top. There will be a deep dive into the Autopilot later today by my colleague Adam Collard. So that will be at 11 o'clock. And Adam is going to walk you through all of the architectural choices that the Autopilot will make. The idea behind the Autopilot is that you will make vendor choices. So you will choose the software defined storage, the software defined networking vendors that you want to mix into the cloud. We're not as canonical trying to do it all. We do provide Swift and Stack, Swift and Seth reference storage that is fully supported. But we are working with many vendors and a large ecosystem to bring their storage offerings into this Autopilot. So let's go and build a cloud. So I'll go to the OpenStack tab. This OpenStack is connected up to Metal as a service, MAS, which knows about the hardware in this data center. And it's going to allow me to make just a simple set of choices. What I want to call this cloud, Region 1, Cloud 1, the hypervisor that I want to choose, the software defined networking. Now we have added, during the beta period, we have added support for open daylight. So you can now choose either Neutrons Open V-switch, or you can add Open Daylight to control Open V-switch. And we are working with a series of additional software defined network vendors to bring their SDN solutions into this Autopilot so that you can evaluate them very easily. And you can deploy them very easily. So I'm just going to go do this. You'll see that all of the networking is filled out because the underlying physical layer in Metal as a service, MAS, is completely modeled on the network. So we know what IP addresses are available. We know which networks to use for Internet access and so on. So all of this information is filled out for me. I don't have to coordinate very closely with network administrators. So I'll just make simple choices. Those are all the technology choices that I'm going to make. This is a physical zone. So I'm going to say, right, let's, I'm just going to make one physical zone in that cloud. And I can kick that off. And the Autopilot will now build a cloud on that hardware using our canonicals reference architecture for that scale. It's a small cloud, only four, six servers. But that will now be a reference architecture for that scale. Their architecture, of course, would be different if it was 80 nodes because then we will place the services differently and Adam will walk you through the choices that we're making in that regard. Okay, so in this tab, I have an Autopilot run which has completed. So this is a cloud that we built earlier this morning. And you see that I have a management dashboard for that cloud. So landscape is a management product, it sees the underlying hosts and it can provide management services there, package updates, kernel updates and so on. But now it can also understand the cloud that's running on all of those hosts. And that collaboration between insights at the host level and insights at the cloud level is incredibly important for our ability to operate that cloud completely automatically. So you don't need specialist skills to operate this cloud, kernel updates, package updates, everything that you need to keep the underlying infrastructure secure will be done entirely automatically with no disruption to guest workloads. This is a supercomputer that runs itself. So we've shown this dashboard before but we've added something in the final push to the GA. We've added the ability to take an existing cloud that was deployed with the Autopilot and grow it. So here in this cloud, there are two availability zones down here, you can see region one, one dash one, region one dash two. And I can go into one of those and add hardware. So here is a machine in the same physical availability zones. And here is a machine. So I could go and add another machine to this to these. And if I had enough hardware or if I installed new racks that were powered separately and decided that that is a new availability zone, I could actually add an entire availability zone to this running cloud while it's running with no disruption to end user experience. So your users will just see the cloud getting bigger, getting better, getting faster. Now the really important thing here is that this is the reference architecture for that scale. And as we update the software, the cloud that it is driving will improve because the reference architecture will improve. We can dynamically move portions around to evolve the reference architecture. And the reason that we're doing that is because we install all of the services that drive this cloud, we install them in containers. We have been doing that for two years. Canonical leads the work in the underlying work in the Linux containers project, which is focused on the use of containers as very lightweight VMs. So we're not talking about the application container or process container approach that Docker uses. We collaborate with Docker, you can run Docker inside Lexi containers. We're talking about machine containers that look just like VMs. And so we place all of the OpenStack services in their own container. And Adam will take you through the rationale, the details, how we defend that against attacks of various forms in his talk a little bit later. So let me see if I can go. So the OpenStack autopilot will be generally available on the 10th of November. We place those services in containers because containers are a fantastic way to operate. People love VMs, they use VMs. And what we've decided to do is focus on the use of containers as lighter VMs. And so that's led us to underwrite Lexi, the Linux containers project, and now LexD, which turns that into a full hypervisor. So LexD is a pure container hypervisor. We announced it at the last OpenStack and we announced it as some initial results that we had in density. We announced we had 14 times the density for LexD than is achievable with KVM. And this OpenStack cycle we're able to show you some additional results for LexD as a hypervisor, specifically focused around throughput and latency. And I want to encourage you to come to a talk right after this one by my colleague James Page. James will take us through the underlying benchmarking that supports these results. LexD as an incredibly consistent provider of throughput in a congested cloud environment. In other words, if you care about throughput, IO, Jitter, then LexD is going to be an important hypervisor for you to mix in to your cloud alongside KVM. We see, for example, results in Hadoop and in similar throughput-oriented applications, which really support the idea that containers give you dramatically improved IO and throughput in a congested cloud environment, in an overcommitted cloud environment. Similarly for latency, we see dramatically better latency when you're using machine containers rather than virtualized machines. And James will take you through all of the underlying information that supports that. Now, there's nothing wrong with KVM. We have more KVM in production on Ubuntu than on any other Linux. And we support it. We love it. We put a lot of work into optimizing it and improving it in our LTS releases. But this is an extraordinary in advance. And it is something that every cloud operator should understand, especially those for whom throughput and latency and Jitter are priorities. So we call it the world's fastest hypervisor. We are working with Silicon vendors to ensure that we can guarantee isolation and security of these containers. There will be a deeper dive into LexD later today and here at the summit. But we are confident that any OpenStack built with LexD will be the fastest possible cloud. You will get bare metal performance. And this is really important if you look at the debates around how you provide bare metal capacity to users. There is demand in public clouds for bare metal. But it's not really for bare metal. It's for bare metal performance and stability. And we believe the right way to do that is to put a single container on that machine, not to feed the whole machine to the user. And the reason for that is that if you put a container on the machine, and it's the only container on the machine, you will get all the bare metal performance, you will get all the cores, all the memory bandwidth, all the disk IO that you would have got if you had the machine, but you will not get the ability to touch the firmware or the BIOS or other areas which we don't believe makes sense in a public cloud environment. So rather than pursuing things like bare metal provisioning through NOVA with Ironic, we think LexD with scheduler enhancements to place a single container on a machine is a far more manageable and sensible approach. It will also allow you to live migrate that single container to a different machine which gives you a fantastic operating experience for your customer, something that they expect from clouds but now can get with bare metal performance. So come along to or stick around for James Page's talk right after mine. Okay. We spend a lot of time looking at scale out and data centers and we look at the performance optimization of the rack and all the things we can put into the rack, you know, open stack on every machine, hyperconverged architectures where we blend storage and compute. What we don't spend a lot of time thinking about here at open stack is what's on top of all of that. If I asked you what's on top of open stack, you might put out a vendor name, right? But the way we think of it is that what's on top of that is the top of rack switching the fabric. And increasingly, the network itself is an area of innovation inside large public clouds. You probably know that the very largest public clouds essentially drive their own network innovation, building on top of standard or industry standard commodity parts and then structuring the network control layer to suit their data center design and their operating philosophy. Much to our delight, the developer passion for Ubuntu has made it a great platform for innovation in the network itself, in the switch itself. And we learned recently that one of the world's largest public clouds builds all of its network control technology on Ubuntu. We have been working with switch vendors, open switch vendors, to support innovation in the fabric. And we have seen a great number of people essentially building their own switches with Ubuntu. But it was a surprise and a delight to us to realize that that had reached the very largest public clouds. So I want to dive in a little bit and talk about how we think that layer, that complementary layer to the compute substrate of an open stack cloud will evolve. In the last couple of years, what we've seen is that Linux is driving innovation in a very wide range of places. We had the great privilege recently of announcing in the same week that we would work with IBM to put Ubuntu on the world's largest computers, new Z series mainframes dedicated to Linux, the world's most powerful individual computers. The same week, we launched a new version of Ubuntu for the Raspberry Pi, a tiny, tiny computer. And that's just to give you a sense of the the spread of Linux and the spread of innovation on Linux today. Over that last couple of years, we've been looking at innovation in these tiny form factors and in distributed kinds of environment, thinking about the Linux that's inside the Wi Fi that access points, thinking about Linux that's inside control units that might be doing industrial control and thinking about what it takes to operate those distributed environments in in an efficient way. If you think about it in a data center, you've got 100,000 machines, but you've got many professionals looking at those machines and lots of tooling and the ability to fix something if it goes wrong because you're close to it, right? But imagine all the Wi Fi access points in the world, right? If one of those breaks, someone has to roll a truck. Someone has to go there in person and fix that. So we looked at what it would take to take to take Ubuntu which developers love for innovation and make it suitable for these very distributed environments where fixing things is very expensive and where developers want absolute certainty about how that environment's going to behave. Now in Ubuntu, you get a file system and you have this great experience as a developer, you can pull whatever you like, bring it into the file system, any package can write anywhere. So it's really easy to combine stuff and make a fantastic, you know, a fantastic experience. So innovation at that speed is tremendous. People love Ubuntu for that. But there is a dark side to that, right? Any package can write to any file and they can conflict. Both package, two packages might want to essentially update the same configuration file. And that means that you can get into a situation where you have to make human decisions about who wins or how to deal with an upgrade where two pieces of software are both essentially sharing that file. And that makes managing Linux or any traditional operating system at scale expensive. You need, you know, a Linux professional to manage a thousand Linux devices when they run this way, right? So they have to be able to SSH places and do apt-get upgrade. But what if we could rethink the operating system? What if we could say, let's separate it into a collection of parts which cannot collide with each other. So we'll need one part there which is the operating itself, operating system itself. So we call that a snap, the OS snap. And we'll need a part which is the kernel. And those need to be different parts because maybe on this device you want to use this kernel and on this device you want to use that kernel, but you want the same OS, right? Those things are read only. That means they can't be modified. They can't be touched, right? They can be updated, but they can be updated transactionally. I can have two copies, the old copy and the new copy. And depending on which one I use, I've either updated or I haven't. And that allows us to update the system and roll it back perfectly. Of course, everything being read only is tricky. Each of those needs a writable space. The kernel will have some config, some state, the OS the same. But we keep those spaces separate from each other. So this kernel that somebody made for their device can't go and modify what the OS can modify and vice versa. And we enforce the separation using modern kernel security semantics, app armor. And then, of course, we can put apps on top of that device. But again, we keep those apps separate from one another. This is, in fact, the technology that we built as part of our efforts to make it possible to run mobile devices. This is an iPhone without the GUI. And it enables us to do things like top of rack switches in a very clean way. Because it lets us say, look, traditionally you would buy the switch with all the software installed. Then people said we should disaggregate and we should have the switch and some firmware. And I should have choice of firmware from a bunch of different vendors. Now we're taking the natural next step. You can buy the hardware from one of any number of vendors, open switch hardware. You can then use a thin and neutral core OS that doesn't do anything to do with networking. That's Ubuntu Core. And then you can choose the network control app from the vendor of your choice. And so this week we're delighted to announce collaboration with these three open switch manufacturers, Quanta, Ajeema and Penguin Computing. And so Ubuntu Core will run on all of their high end programmable open switches. And we're also delighted to announce that a number of the network control vendors, the software vendors who essentially have new algorithms for controlling networks at scale, will sit on top of that as a series of SNAPs. Making it incredibly easy for telcos, operators and other large scale data centers to evaluate different network control technologies without having to essentially reflash entire operating systems, just picking a different app effectively to control the network. But we can go further. We can now add additional applications on the switch. We can add network security applications in the very place which sees all the networking. We can do rack management in the switch. It's on the top of the rack. And we think this is going to be a very fertile area of innovation with people essentially treating the switch now as an addressable device for pure software play innovation. So I want to show you that in a demo. This is a quote from Ajima Systems who have said that this strategy allows them to focus on the core innovation rather than having to do the entire stack. And we see that same sentiment being echoed by many of our new partners. So I have here two switches, one from Penguin, one from Quanta, and I start with the one from Penguin. In fact, that has no operating system on it. What I'd like to do is put an operating system on it. Do you know what I completely forgot to do? I completely forgot to show you. Open stack running with the device. So here I have MAZ. In fact, this is this metal as a service. And these two switches have been registered in MAZ. So I now see them down here as devices. One of them is switched on, the Quanta device. Quanta switch is switched on. Powered up. I'll come to that in a second. But the Penguin computing on the yellow one isn't. So I'm going to go to this device and just turn it on through MAZ. And I'm not just going to turn it on. I'm going to install the operating system on it. Let me see if I've got this right. I'm going to install the operating system on it. And so I'm going to turn it on from scratch. There it's booting. So I've got a serial interface through to it. So you're actually watching this device boot from scratch. There is no operating system. There's simply a operating system installer called ONI from the open compute project. And I'm just going to jump out of that. So ONI allows me at this point to report to conduct a couple of sort of firmware management operations. But if I just go ahead and say install the operating system, you'll see what it does is comes out and looks on the network, asks MAZ for an operating system. It's just getting an IP address. Now it's going to grab an operating system installer and it will install Ubuntu Core. So that's Ubuntu Core. Just that thin, neutral operating system switch from scratch. So there it's found an image. It's going to repartition the device. So it's going to essentially clear the disk and now it's going to install Ubuntu Core on that switch. And in just a couple of minutes you've all seen MAZ installing operating systems on servers before. Here it is installing the operating system on a switch. In just a couple of minutes that will be installed. This is what we made earlier. This is the quantum computing switch below which we installed through MAZ a little earlier this morning. I can log into it. And you can see that I'm running Ubuntu but not traditional Ubuntu. So apt-get update doesn't work. This is snappy Ubuntu. And so if I say snappy list you can see the snaps that are installed on the system. You've got Ubuntu Core, that's the OS snap. You've got GenericMD64, that's the kernel snap. And then two additional ones WebDM and BCOS. BCOS is a reference network control snap from Canonical. So it allows us to do large volume testing, discovery, validation and so on of network switches. And what I'm going to do is just show you that it is in fact a switch. This will be familiar to those of you who have worked with modern switches. You can see this is a Broadcom 56854. This is the quanta device. I can do show ports. So you can see all of the 10 gig ports on the front as well as the 40 gigs somewhere in here. And you can show the MAC address table here. So now using that switch just as anybody as you would expect to use a switch but instead of just having one monolithic piece of firmware, I actually have choice. I could use a number of different network control control plane apps effectively. This allows me very quickly to innovate and test and evaluate new strategies for my top of rack switching. And we're working with both and bright box and some of the traditional branded switch vendors to bring this level of innovation to your top of rack. Now there was another snap on here which was called WebDM. And to show you what that does I want to go to this machine in a web browser. I'm going to go to port 4200 and this is something called WebDM. It is in fact a web based device management system. This is a standard service that you can install on any snappy Ubuntu core device. It's just another snap but it allows me to manage that device through the web. So I can now see that I've got that kernel Ubuntu core WebDM and Bcos installed on this quanta switch and see that through the web. And I can go into a store. So this switch now has an app store on the switch which would give me a startling array of things including Minecraft. Minecraft on a switch. I'm not going to install any of those. But I think you get a sense of the potential for innovation that this could unlock. Traditionally the switch was closed. Then it became that the switch was sort of open but not really addressable for developers because you'd have to go and work with the firmware manufacturer. Now you can just write a snap and put it on any top of rack switch. So the switch is now addressable by developers through an app store. Okay, let me come back to this little bit of magic. This is in fact OpenStack running on this half rack, effectively 10 micro Intel servers with LexD as a hypervisor. So you can see all of these instances all of these instances are not VMs. These are these are containers. And if I go into the admin view of this, you can see that the machines that underpin this cloud are using or providing LexD as a hypervisor not KVM as a hypervisor. So that tiny little prototype half rack, the 10 Intel nooks could run thousands of containers. It's a fantastic way to give your developers very rapid access to capacity for DevOps or high throughput low latency clouds if you want to do it in production. The important thing here is that nothing changed. This is just horizon. I'm just using standard images. All of my software just works. We are working furiously. Canonical leads the work in the kernel and LexD and elsewhere to ensure that you won't know the difference between a container and a Linux virtual machine. Okay. So I've talked about the economics of cloud. Now managing cost and what we're doing to essentially make it possible to operate open stack very easily, very cheaply, very efficiently at great scale and with the ability to mix in your choice of vendor of preferred vendor for storage network administration monitoring and so on right. But managing cost is only half the challenge. The other half of the economic challenges revenue, consumption consumption, users. We have seen and I think it was very important that we see the consequences of failing to understand this equation in the failure of HP public cloud. It was cheaper to turn the disks off than to keep the disks spinning. And that is a very sobering thought for anybody who's getting into open stack. You must understand both the imperative to manage costs and the imperative to attract users to drive consumption. Consumption is revenue is growth. That is true of a private cloud as well right. Your usage is your revenue. You are selling to your internal users. So how are you going to how are you going to attract those users? What are the barriers to adoption? Are you offering your users plain raw virtual machines which they have to SSH to which they have to then configure? Or are you driving them to solutions? So I'm delighted today to announce the Juju App Store for OpenStack. And this is the culmination of the work that we have been doing with many ISVs around the world to enable their applications to launch, to scale and to integrate automatically without any sophisticated user engagement right on any cloud environment. It's really important that this works everywhere not just on OpenStack because ISVs must address the global market. But today we're focused on OpenStack and so I want to show you the Juju App Store for OpenStack. Now my colleague Rick Harding is going to go into this in great detail at 20 to 3 this afternoon and I would really encourage you to join us for that presentation. Very briefly here I'm running an OpenStack and as you can see I've got a bunch of instances a bunch of machines running in that OpenStack it is difficult to know what that is doing, right? It's just a whole bunch of machines and a whole bunch of block devices it's difficult to really know what that's doing it would be difficult for someone to look at that and know where to go to kind of scale out any of those applications Everything looks like a normal OpenStack in here we have heat, we have networks, we have Swift, we have Ceph but we've added a new tab here which is the Juju App Store embedded into Horizon and in that App Store I'll need to just peek behind the curtain in that App Store suddenly you have meaning right here I've got a substantial big data deployment in progress you can just zoom out a little bit so that's Hadoop, Spark Hive, MySQL Yon a whole bunch of things those VMs that you were looking at earlier this is what they're actually doing and any user can create this just by dragging and dropping from a web based store onto their OpenStack Cloud so this is how solution providers, service providers and internal IT can stand up a cloud and then realistically hope to attract very rapid consumption adoption and utilization of that cloud we will launch with a portfolio of applications from a wide range of ISVs for service providers and for private clouds I'd like to introduce you to my colleague Stefan Johansson Stefan will be leading the effort engaging with both service providers solution providers, telcos and large enterprises to integrate this into their OpenStack clouds I want to emphasize that the way we've done this is not specific to Canonical's OpenStack if you have chosen BlueBox as a managed service provider you can integrate this very easily all of the plugin mechanisms are upstream we've pushed them upstream so that Horizon is extensible and so this can be integrated into OpenStack, Red Hat OpenStack the OpenStack of your choice we know that 65% of those OpenStacks are running on Ubuntu we'd be delighted to bring this to the other 35% as well we see this as an important and useful accelerator of OpenStack in the market very quickly I can switch between different environments so this is on the same cloud as somebody else who's deployed Kubernetes so this is Kubernetes, drag and drop and of course if I wanted to I could go and make a new model and then drag and drop items from the store straight into that cloud so this is me deploying WordPress and my SQL and a blog trivially without any SSH without any IP address without any underlying knowledge of how that works into that OpenStack cloud a really powerful and transformational new capability in the OpenStack ecosystem so this next release is an LTS release for us, two years ago we were preparing for 14.04 and Ice House if you look at the data that was the single most popular release of OpenStack that remains an incredibly important release of OpenStack because we made it, declared it to be an LTS supported it as an LTS you may know that the LTS term is something canonical first used to designate our enterprise releases where we make a long term support commitment it's now a more widely used term in the open source industry you'll find people talking about an LTS kernel so long term support obviously that means that our focus is on resilience, scale and operations we will support the market on both 14.04 and 16.04 we support upgrades of the cloud and if you want to see an incredible session come along at is it 11.30 I think it's 11.30 for Billy's session on 3.30 this afternoon on amazing operations of OpenStack we will do a live upgrade of OpenStack on stage from one version to another we support that we do that today some say it's impossible we do it all the time for customers to enable them to get new versions of OpenStack very easily we will support that on 14.04 all the way up to Mitaka and then we will support Mitaka on 16.04 as well and upgrades to N, O and beyond we will automatically update clouds so the autopilot will do automatic upgrades this is what the release cycle of OpenStack looks like when it's overlaid it's not an accident that those releases line up and you can see how we make it very easy for you to stay on OpenStack as it evolves we have recently added extended support for the middle releases so one release every year gets extended support for our customers only and that is extended support currently for Kilo it will also be for the O release two releases after Mitaka and so that allows people who are building clouds and want who don't want to upgrade them to know that every year they will be able to stay for an extended period of time on that interim release of OpenStack I am happy to be here in Tokyo it's a real privilege to see everybody in the OpenStack ecosystem again I hope this has been useful I hope that some of these talks later today will be of particular interest to you I really want to thank my colleagues who have made all of this possible and hope you have a phenomenal OpenStack summit thank you very much