 Okay, welcome. We're gonna kick off. So we're from StackStorm We're gonna talk a little bit about Operations automation and our particular focus and some of the use cases in ways people are using StackStorm StackStorm was open sourced yesterday It's an Apache license. So please go and grab it take a look at stackstorm.com slash community I mean you could be downloading it as you sit there. So Don't wait grab the bits. I had a high level. This is what it is now after I walk through this We're gonna actually demo a particular remediation But what you're gonna see is we're gonna be listening to some events We're gonna then take actions based on those events and those actions are going to include workflow So long running actions tied together in a conditional way Um Sometimes stackstorms sort of called the wiring for your Legos, which is okay a little a little weird Or if then then that for the enterprise Again events on one side actions on the other in between some logic that helps you make those decisions and then share As code how you want to make those decisions going forward whether it's CICD pretty common use case these days or Troubleshooting facilitated troubleshooting Or what we're going to show you again is an example of remediation I probably should have introduced myself. I'm evan pal One of the co-founders of stackstorm. We're at booth e2 over there We're giving out like the best swag in the entire show. So stop by Including beard combs Come on beard combs And so i'm evan pal. This is patrick and i'm going to hand off to patrick All right, let me pull this up here. So the general idea for our demo The general idea for our demo is that an event comes in from a monitoring system. We'll say sensu And that particular event is indicating that there is an issue with a piece of hardware on a compute node, okay So We have a rule within our system that's going to go ahead and match against that particular event That's coming into the system and it's going to fire off a workflow that evacuates all of the Instances off of the compute node and takes care of the remediation for you Basically taken straight from the open stack troubleshooting guide You can see here that we actually have the ability to take criteria from the payload of the event and match against it to do that that logic that evan was talking about the decision making to decide Whether or not the event that's come in really is actionable So if we take a look at the action So this over here is the definition of the evacuate compute workflow if you will What it basically does is it takes a bunch of atomic actions that we've defined within our system Just small units of things like getting a list of instances or sending out an email and it stitches them together into a workflow With conditional logic based off of you know on success and on failure states for those actions The beauty of the workflow is that it allows you to to bubble up that logic and and and that Entire workflow out of your scripts This is something that would normally exist within an operation engineer script or something like that But we're going to take that out of it and use the mistral workflow engine to actually To actually perform all these tasks with the the ability to exit on error So if we take a look over here at the history, we can actually see one of these I ran So this is the this is the workflow that I ran here and we can actually see all of those steps that ran For the workflow, so what it did was it went and it ran it got the list of instances for the failing compute node And if we actually look We can see the payload of that trigger that came from the sensu alert is here And so it tells me that it's compute two that was failing It tells me that the tiddly bit is actually the piece of hardware that was failing And and it goes ahead and Tells me that the state was critical So this is the the input that was given to the workflow And so it went and it took that that input and it passed it on through to the actions And so we can see that this action the first one that ran was going and getting the list of instances That were running on the compute two node And so it passed in the host name of compute two And then we can see down here the actual output of that particular action As we go through the list of actions We then went and got the the owners of each one of those instances that was on that compute node We sent out a batch mail to all of those owners saying there's been a problem on the underlying node Or on the underlying compute node. We're going to evacuate your your guest to another node We then Disabled the compute service on that node Did the migration for the the instances? And then we confirmed that the migration was successful um, so it Goes through the entire process of doing all this and an additional step that you could add in here is something like Submitting a jira ticket to replace the the failing piece of hardware that the tiddly bit in this case that you had been notified of By the sensu alert So you're able to tie together all of these actions that are both Inside and outside of open stack like the batch mail was just a send mail command Um, that's not something that's inherently part of open stack, but you can stitch that together into the workflow um The nice thing about this is that this is all Done automatically for you, but you don't have to have the automatic remediation done You could have just the diagnostic work done where it goes and looks at information about the failing node And then spits that out into a collaborative fashion that's it's The workflow is very flexible in how you go about it We also ship here with a full command line client So the command line client just like the open stack command line clients Uh, it has python binding So if you want to have meta automation and wrap your automation in automations you could potentially do that Um, but you can see here the action list like which is the same as I was showing through the ui before or the rule list Or actually there's that full history like we had looked at all just available through the command line And there you can see just the specific information return from a specific from from an execution result. So We talked about amazon and open stack and you might ask what why are we talking about aws at an open stack event? Well part of the power of this kind of solution And by the way, we didn't come up with this idea per se a lot of the larger operators have written something like this themselves Is that you're now abstracting away your logic? So there's remediation path From the underlying which cloud is it? So stack storm we also help sponsor a project called lib cloud And contribute pretty heavily to that project And so while open stack is where our roots are The same logic can be easily applied to aws or the combination of the two or rack space or name your cloud We very likely already have that integration. So just Again part of the value here is being able to share these operational patterns Irrespective of whether you have this or that particular cloud or set of infrastructure underneath Yeah, it's a very good point Evan. It's it's completely agnostic is kind of the idea We've made it very simple to add in the the integrations both from the action side and from the event side And so Whether it's open stack or another cloud or or you use nagios or you use sensu It's very easy to integrate any one of those tools into the system And on top of this you get the full audit history across all of those tools Which isn't something that you're normally going to get when you're just scripting things together We just recently open sourced yesterday So we open source our code, but we also open sourced our contribution repo or our integration packs And so what we're really looking to do is we'd like to get people out there to try this out Download it play with it See what what integration packs do you think that or we need or one of your gracious packs? Would you like to write? Um Write those and then submit a pull request to us and and and we'll pull it into our repo or or send us a link to The repo where you've put your integration pack and we'll publicize it and you know Put it out on our blog or our site and and really get it out there and let people know that these other integrations are out there Because we we really want to get On top of the integrations we've written we want to be able to integrate with with just about anything And we've we've made it easy to write that we just want to see people get out there and write it so so What questions do you have? A lot of power I think obviously i'm biased, but uh and the demo is pretty simple, right? I mean we're just showing you how to tie events into actions that you can take We've shown you that remediation use case We're also using c-i-c-d. So let let's say the event comes from jinkins You can imagine you have a whole series of events that you might want to take in a workflow like way with conditional logic in between them We have audit underneath as you said patrick so that the whole thing's tied together so you can learn um, and you're seeing i mean we're just showing you github, but You're now literally sharing infrastructure as code like your operational patterns But what questions any any questions come to mind? What is it you do? No flood Thank you You want to answer or yeah, yeah, so that very good question So the question was if you have existing operational scripts and you want to use them in the system Can you use them in the system and yes you can any script can be added? It's run remotely over ssh So we can run anything that can be run remotely on those hosts You add the actions with just by simply writing a five-line json file that defines the name and the description path to the script and the parameters Incidentally, we also have a A utility that we wrote that will consume fab files from fabric And it will actually take all of the fabric tasks and auto generate the metadata for each one of those tasks So that you can add each one of those tasks as an individual action into the system without having to write those json files Yeah, so we're not saying throw out your scripts. We're saying It may be getting to be a little bit of a headache to maintain all of these You have, you know, five six ten packages underneath that you're integrating to that's 25 to 100 different integrations You have who knows how many scripts authored by who knows how many people Um, do you want to spend your time maintaining those integrations and those scripts? Or actually adding business value let us ingest those scripts. It's an open source project You get all the integrations from the community for free. You get the rules engine for free You get the workflow the audit, etc GUIs for free and now you can focus on more high value added stuff as opposed to thinking now How did we write that script? What happened to the guy who wrote that script? Etc. So it's really, uh, hopefully removing some of the technical debt at the automation layer Other questions Yes So what what's it like to integrate a legacy or an existing system? So it it really depends so out of the box we ship with the with a generic web hook sensor We also ship with a timer sensor where you can fire things on a timer interval But we ship with the generic web hook So if whatever your legacy system has the ability to send out an event you can send it to that web hook But if that's not something that you can do if it's more Where you would have to reach out and gather that data We've made the sensor interface also very easy to write Currently they can only be written in python, but it is very easy to write the sensor So the sensor would run on the system and it would reach out to those legacy apps polling for that data And then if the sensor decided it was appropriate it would emit the trigger into the system Which would then go through the rules engine Etc. Etc. Thank you. Any other questions? Yeah, I mean one of the I haven't kind of touched on it But one of the important Aspects that I really see to this is that it does abstract away the actual workflow and the actual Procedures that you're going through to do these things away from the underlying Code that needs to be used to run those so you can actually take and you can start to version control and and Iterate across the procedures the workflows themselves and decide how better to streamline your process By using something like this and and having the workflow engine in place And so I think that that's one of the really important aspects that that kind of bubbles up out of this Once you once you've already tied in the integrations and you start to use it You start to realize how you can really improve those processes Yeah, just a quick point on that is if you compare us to a solution like microsoft system center orchestrator And that that's a solution we know pretty well because our my co-founder Ran engineering at the company that microsoft bought for that product or any of the legacy automation solutions They don't do what patrick just said. They don't allow you to easily externalize as code Your procedures they're take them in but they won't give them back Additionally same idea on the integrations very hard to share those as code And then they themselves the legacy automation solutions aren't very automatable They just don't fit in today's world of loosely coupled tools tied together Question. Yep. Did you get that? Yeah so the So the like an action you're talking about if an action is performed So the action scripts are actually copied out and any libraries that are required for the action script is copied out With that action script it's then ran on the remote host and then removed So you don't actually have to have those living you don't have to have a copy of your repo Yeah, exactly because not every action pertains to every host, right? So so it's we just copy out the bits that are necessary for that Particular invocation of that action and then we remove it at the end any other questions Yeah, so well mistral is the workflow engine behind what we're using we actually heavily utilize mistral and that's why we've contributed as much as we do to mistral but When you really look at the full-blown audit and you look at the the power of the rules engine here And and how easily the the sensors are written and the incoming events is done That's where all the power is mistral is very good at the the workflow piece And that's why we leverage it here, but but it when you talk about the audit and the rules engine and all that That's really what what we're bringing to the to the table and all the the rich integrations That's the other thing too is that out of the box Mistral is not going to ship with rich integration with the Your third party utilities outside of the opensack projects So we'd love to chat with you more booth e2 Also, you can go to stackstorm.com slash community, you know grab the bits now I said that at the beginning so by now somebody should have grabbed the bits and I did any pull requests Yeah, I I expect to see pull requests when I get back to get back to the booth So I hope you guys have written your integrations already. So seriously we're an open source Company open source project really excited to help deal with this Really it's starting to be technical debt at the automation layer and but we need to all kind of pitch in and We're there to help But we think the integrations and even the operational patterns as code sharing those it's going to help us all move faster So thank you, you know, thank thanks for your attention Yeah, and please feel free to reach out pound stack storm on free note or or Any one of these ways just reach out to us and if you have questions or or feedback or you just want to chat about the ideas I'm always there and I love to chat. So thank you Thank you