 Good to go. OK, hello. My name is Nolan. I'm the CTO and co-founder of Kemulus Networks. And I'm here to demonstrate a fully automatic deployment of OpenStack and the network to host OpenStack all in 20 minutes. Unfortunately, I just have a video of the demo. Unfortunately, not actually a live stack of hardware here. So who here knows what Kemulus Linux is? OK, handful. So for everyone else, Kemulus Linux is a network operating system that runs on what we call Open Networking Switches. And so the basic idea is that, unlike the traditional switching market where you would buy an appliance from a vendor and it would have the OS, the hardware, all bundled together, and it would have a fixed set of functionality and a fixed set of software. We treat it more like the server's market, where I can buy hardware from one vendor. I can buy an operating system from another vendor. And then I can put whatever applications on top I want. Open source applications that run on Linux, stuff I've written, really anything that solves the problems that you have. So to this end, we developed a piece of technology that's key to this automation demo called ONI. ONI is the open network installer environment. We actually contributed to the Facebook Open Compute project, so it's open source. And it is the installer that lives on these Open Networking Switches when they come out of the factory. And so what it does is allows you to basically pixie install a network operating system. But unlike pixie, you can use IPv6, SFTP, HTTPS, all sorts of things that are better than TFTP. So Chemulus Linux itself is a Linux distribution based on Debian. And it is really based on Debian. You SSH in, and you get a bash prompt. And so that allows us to leverage quite a bit of automation tools and monitoring tools and all the things that are developed for Linux already that people use on the servers. The only difference is, unlike a server, we have a forwarding ASIC that can do line rate forwarding out all the various front panel ports, up to 32 by 100 gig these days. So here's the standard OpenStack diagram that you've probably seen 100 times today. So the automated deployment we're going to push out today to keep it simple is just your very standard MLag with VLAN. So we're not going to be doing any sophisticated SDN, any VXLAN overlays, anything like that. Because this is just about automation. If you want to learn about VXLAN overlays, come see my talk tomorrow with Mark McLean, and we'll get down in the gory details. So as I said, very simple MLag configuration. Each hypervisor is connected to the two top-of-rack switches, which are configured in MLag to appear to be a single bond to a single switch, as far as the server is concerned. And this provides high availability and double the bandwidth. And so you've probably seen this kind of style of network diagram 100 times. It's a pair of spines in an MLag configuration, and then pair of top-of-rack switches, one for rack. And we can scale it out up until we run out of ports on the spine. So you can build fairly large networks. Actually, usually you'll run into scalability limits of the large layer of two domains you end up with before you hit kind of the actual cabling scalability limits. So we're going to make some assumptions for this demo environment, which may or may not match your real environments. You may have to modify things a little bit, but we're assuming there's no internet access, so everything has to be self-contained for the install. We're assuming the kind of dual connections for the switches and servers. And we're assuming that there's an out-of-band network, a management network that connects the management ports of all the switches and also the kind of IPMI pixie ports of all the servers. So the deployment happens in two phases. The first step is you plug a USB key into one of the switches. Traditionally, we use the leftmost spine switch. Cumulus Linux will install via ONI from that USB key. Once that's done, we'll use a technology called ZTP, which is zero touch provisioning, to pull a configuration script off that USB key. That configuration script will configure that spine, in this case, Spine 01, given the naming, to be an ONI and a pixie server. So ONI server is going to be able to install on all the rest of the switches. And the pixie server is going to be able to install the OS on the servers. Furthermore, it'll configure itself as an HTTP configuration server with a fairly simple Python program that can serve the configuration that the other switches, the other spine switch and all the leaf switches need to configure the network. And then finally, that switch will be the puppet master for the servers to then install OpenStack and configure it using puppet. And so the second phase, once that first switch is installed and configured is all of the other switches and all of the servers in parallel, install their OSes and configure themselves using ZTP for the Cumulus Linux and using puppet for the OpenStack servers. So here you can see the USB key being inserted. And here you will play the video so you can see all this in action. We've sped it up quite a bit because 20 minutes is kind of a long time to watch text scrolling by. So here we are unboxing the switch. This one looks like a Dell S6000, which is a 32 by 40 gig switch with an Intel x86 processor in it. And so you can see all the 32, 40 gig ports on the front there. And then you can see the cabling. This is going to connect it to the leaf switches. And then this switch will be the one, this will be the Spino one that actually will have the USB key installed and will act as kind of the root installer for all of the rest of the servers and switches. So you can see the USB key. You power it up, right? At this point, the entire process is hands off. No, yes, our marketing department got cute with the flying turtles. So now you can actually see this first switch is booting here. And it's reading Cumulus Linux off of the USB stick. And this is actually why it takes 20 minutes. This switch has relatively slow storage, so it takes a long time to install Cumulus Linux onto it. Some of the more modern switches, some of the newer switches I should say, have SSDs instead of kind of compact flashcards. So they do this a lot faster. So now you can see Cumulus Linux booting for the first time. We're getting a couple of failures there because it's not licensed yet. The license file will be installed along with the configuration by the ZTP process. It's also gonna configure the Pixie and Oni servers for the rest of the switches and servers and configure the Puppet Master. And so the Puppet Master started, so now you can see Spino 1 has its name. This, if you can read very quickly, is the configuration for the Spino 1's network. It's a very standard MLAG and VLANs. There's nothing terribly exciting there. And so now the rest of the switches, which up until now have just been looking for an Oni server continuously, find one. So now they install Cumulus Linux on themselves and then they configure themselves by asking for their config from that Spino 1 switch. And so now you can see that was very quick, the configuration of all the leaf switches as well. And so concurrently with those other switches installing, the servers were Pixie installing and getting OpenStack installed via Puppet. And so now you can see we've, Puppet has configured Horizon, Nova, Keystone, all the different pieces you need here and to allow us to boot an image. So from 20 minutes to plugging that power cord in and kicking off the process to starting VMs on this new cluster, all without any human intervention. So that's the entire configuration. Any questions? That's correct. The question is, did we use the Puppet modules? You did the upstream from Puppet Labs modules. What's that? Oh, very good. Well, thank you. We found them to be very good to work with. Now you could have also used Puppet to configure the switches as well. In this case, it was such a simple configuration we just basically pulled the config file over HTTP and applied it. But if you had a more complicated config like an SDN layout or something like that, you might want to use something more sophisticated. Great, well, thank you very much.