 Hello. My name is Matt Stone. I'm a software developer with Brocade Communications, and I work specifically on the StackStorm product. And today I'm going to be telling you a little bit about StackStorm. What is event-driven automation? And then I'm going to go into a couple of use cases that we have specifically with OpenStack and StackStorm. So to begin with, I'm going to give you an overview of event-driven automation at large and then also kind of what our view on that is and how we implement that with StackStorm. And kind of the heart of it or the philosophy of it is that a lot of us come from operation backgrounds where we're actually operating networks and operating infrastructures just like you guys. And we understand that there's a lot of pain and sorrow that comes from an infrastructure that fails. And so the heart of what StackStorm is trying to do is actually to take your pain and your suffering and your horror and turn it from the flip desk Jeff meme, which is my favorite ever, to the happy man meme, which is not my favorite ever, but it's okay too. But the reality is it's not exactly a joke, right? Like while it's funny and paints this funny picture, it's actually what we really intend to do. We really intend to help our operators go from those 3 AM calls and turn those into continuing to sleep or continuing to play with your kids after work. And or an automation use case that is really repetitive. We take that and we say okay, don't do that really repetitive thing anymore. Turn that into something that you can repeat and automate. So it's not that uncommon that people will have automation in their network or in their infrastructure. They'll use something like Puppet or Chef or Ansible to get a job done. And they will manually do that. And it's also not that uncommon for them to have monitoring in their network. They will have both of these sitting in isolation. The heart of what event driven automation is trying to do is to try and take those two things and link them together. So when some sort of thing happens on the monitoring side, we transition that into taking action on the infrastructure side. So we have this automation that might say, here's a run book that we do under these circumstances and we have these sensors and these monitoring tools that say, this is a current threshold that we need to look for. So why not link those two things together? And that's at the heart of what Stackstorm is trying to do. And so the kind of the way that we view that at a large level or out of kind of like a philosophical level is these three things. And so this isn't that uncommon from how you approach really any big problem. You kind of take one step. You evaluate where you are. You look at the variables, the data that are associated with where you're at right now. You decide which way you need to go. You have, you confirm that with your team. You decide on that trajectory. You take another step in that direction and you do it again. That's the only really way that you can kind of have these huge complex systems at any kind of scale. And so to turn that kind of philosophical data gram or data image into how that actually is viewed in a software construct, how we actually work from a Stackstorm perspective is best described by these four things. So these are kind of the primitives that make up Stackstorm. On the far left there, you've got sensors, right? And sensors is all about data. You have data inside of your infrastructure that you need to collect and to analyze and do something with. And so a sensor uses that data to produce triggers, okay? So if you've got, for instance, a RAM or CPU utilization is over a certain threshold, that can activate a trigger, okay? And that's very simply what a sensor is. You have data. If that data reaches a certain threshold, trigger. So next is a rule. And that's where we kind of get our if, this, then that type comparison. And a rule consumes a trigger from a sensor, okay? So whenever a trigger happens, a rule links that to a workflow, which, so basically if a trigger is seen, then go run this workflow. And a workflow, very simply, we utilize very heavily and we contribute very heavily to the Mistral project inside of OpenStack. And that is our workflow language. That's how we take the operator knowledge, the operator intent, how he actually typically would go into a device and make configuration changes, et cetera. That's how we capture that, is in a Mistral workflow. And so Mistral workflows can be as simple or as complex as the operator's normal job. So you can have branching, you can have with items, you can have all these different complex things, or you can also just say, do this thing, and if that succeeds, do this thing. And so Mistral is a really powerful tool, and that's how we utilize it. We say, if a trigger is happened, we create a rule that links that to a workflow, and that kind of creates that loop that we were talking about earlier. So workflows consume actions or trigger or instantiate actions or call actions. And actions are very simply just an atomic thing that you would do against a device or a node inside of your network. So if you've got a stack store or an open stack cluster, an action could be go create an instance. If you've got a network switch, an action could be create this IP address or create this VLAN. And so the actions are basically very simply very individual things that you would typically do against a device. And so we collect those things into a workflow, and that's how you create this automation and this complexity that you actually push out and instantiate into the network. So we don't require you to build all of that. We don't just provide you rules and workflows and say you're on your own for the other two. We actually have a relatively extensive amount of integrations. Here's just a screenshot from our GitHub contrib page. And so we integrate with open stack, obviously, and various different other things. I think it's Panasonic or Philips, the Hue light. We actually have one of those where you can change like a light bulbs color from a stack store, which is pretty cool. We have like a small example of that at our booth where you can come and actually see we built with a couple of raspberry pies, a sensor that has a REST API, and then a light bulb that will change based on what that API is doing. So you can kind of visualize what Stackstorm is actually doing in the background. But we don't require you to build everything from scratch. We have plenty of integrations and certainly encourage more. Stackstorm is built entirely in Python. So all of your integrations will be built in Python too. So now I'm going to transition into a couple of use cases. This is by no means the extent of what you can do with Stackstorm. However, it is two, I think, pretty powerful examples of what you can do. And the first one is actually really cool personally for me. It's how Morantis uses it. And so I just copied this diagram back on here and will overlay this with how they're using Stackstorm at each level to automate a potentially kind of an event that would normally wake up an operator. So on the sensor side, Morantis is using Xabix to monitor their infrastructure. So they're looking at, in this particular use case, they're looking at an individual node in their OpenStack cluster to kind of analyze its health. So making sure all the interfaces are up, making sure it's not overutilized from a RAM or CPU perspective, et cetera. So what they do is when they notice there's an issue or a health issue with a node, they'll trigger on the sensor side, which has a rule that says, OK, if you see this trigger, let's go ahead and evacuate all of the guests from that node to another clean node that is in a good healthy state. And so what you do there is you basically, what normally would have been an event where you have to get a human involved and you have to say, OK, this server is having something, an issue that is preventing people from accessing their guests on top of it. You need to go manually evacuate that server. This is actually doing that for them and moving it to another clean server. And so that is a real depiction of you going from flip desk type attitude to, all right, I'm happy. That happened automatically and my customers are happy and I'm happy because I didn't have to get waking up at 3 AM to go do that manually. So that's actually the use case for that Morantis is doing. And I've purposefully not gone into too much detail there because they have an entire talk on that later. And I would really encourage you to go to that talk because they're going to be going into way more detail about what they're doing there, far better than I could because they're the ones that implemented it. All right, so next we are going to talk about, see if I can get my mouse over here. So this is the way that Brocade has chosen to move forward with how we integrate with Neutron. And so effectively we've got Stackstorm sitting in between Neutron and the network. So what that actually gains you is, and this is the workflow that we're going to be running here, but what that gains you is the ability to on a Neutron call run a workflow instead of just an atomic action inside of your network. And so this can actually, you have the ability now to grow that in complexity. So if you're doing relatively complex things in your network, like taking into account bandwidth utilization, et cetera, you can capture that in a workflow. And so this is the workflow that will be run inside of this demo. And so in a second he'll be, this is obviously a video recording, but this will be transitioning to the OpenStack side where we'll create a network. And this is a very simply Brocade's instantiation of like a VXLAN type overlay. And so you've got a VLAN that goes from the host to the network, and then we create BGP pairings with all the top racks, which is to create VXLAN tunnels across that. So right now we're creating that network inside of OpenStack. And then this is the enterprise version of Stackstorm, which is called BWC or Brocade Workflow Composer. And this is a Mistral workflow that's running. So basically you can see here on the previous screen it was going through each item that it was doing. And here we're actually just posting some of the data that we're collecting and running against the network into Slack for chat ops to let your operations know what's happening. And here we're just showing you the switches, the configuration on them, seeing that they're actually changed. So you can see that VLAN 128 was created. We'll swap back to the OpenStack instance and show you that, in fact, VLAN 128 was created. We'll show you the MAC address table to show you that, in fact, there is nothing in it right now because we have no instances created. Then we'll go back into OpenStack and create an instance. So this instance will be put into the VLAN network that we just created. So from the host's perspective, it's just a VLAN down to the switch. But where the complexity is is in the network where it actually creates those VXLAN tunnels. So now that instance is created. What that's doing now is going and provisioning the host ports on the switches to say, OK, this is, in fact, going to utilize VLAN 128 to talk to our network. And then we'll log back into the instance on OpenStack to see that it does, in fact, work and you can ping an address. So here we're showing you the MAC address table to show you that it is populated with the MAC addresses for the instances and then back over to the instance. To run a couple of normal Linux commands, we're showing you that it's configured with the IP address and then we can ping across to another instance. And then we will show you back in the switches those VXLAN tunnels that I was talking about earlier. So there's the tunnels that have been created to handle that node. So I'm a little early. I have a little bit of wrap up to do. But that was two use cases for StackStorm. The primary thing I want to key in on there, especially on that last one, is the ability to kind of utilize Neutron to say, this is a command I want to run against the network. And from StackStorm's perspective, say, OK, that might need to be a more complex workflow. I might need to take more things into account. And so the way that we're leveraging that is really is pretty quite interesting. And so from Burkhead's perspective, we can have that single call into StackStorm actually control various different devices, whether it be an MLX or a VDX, which is two devices that Burkhead sells. And so it's a pretty cool way. I hope that that kind of sums up for you what event driven automation is, what we think event driven automation is. And just to reiterate, if you want to come by our booth and take a deep dive into some of these topics, I would really encourage you to. Because there's only so much I can do in a 20 minute presentation about these concepts. As you well know, if you're into automation at all, that these things can get really complex pretty quickly. And so if you're interested in these topics, want to have a deep dive conversation, we'll be at the booth. We have a demo, like I said, at the booth that you can see that's relatively cool. I spend a lot of time on it, so I think it's cooler than most people. But it's pretty cool. It shows you a physical representation of what StackStorm is, and we can go into deeper topics about this stuff. So if you want, we also have a giveaway that we're doing, where we're giving away a GoPro and a Raspberry Pi. And the way that you are eligible for that is a hacker style CTF type games. It's inspired by some of the contests they do at Defcon. So if you've got a little time and you want to spend it solving some puzzles, come by and see us. We're giving away some stuff for that. And again, the Mirantis talk, please go see that. That'll give you some more information as well. And I hope to see you at the booth. Thank you.