Senseless acts of automation

Possibilities can become reality…..if you just think of enough stupid things!

Truly being a Mad Scientist these days. I would always say that with stackstorm I can automate just about anything. Well, My dream has always been to tweet a vlan into my data center. Yes, you’re proably rubbing your chin saying the cheese has slid off this wookie’s cracker.
But not so fast! If you think about what you have to do to make this task happen, in an automated fashion, then maybe it’s just not so dumb after all.
We don’t want to have to pick up our phone a tweet every time we want to test our app, do we? So we start with the fun little app to send a tweet for us.
It’s OK security buffs, I changed the oAuth token…Next we are going to have to make a stackstorm pack. It’s just a bunch of folders so we can keep everything together.
Now we need to depend on the twitter sensor so we need to install the st2 pack. st2 pack install twitter. In the sensor folder we will find the sensor, it looks like this.
You can see where it wants the oAuth token. So we add that information to the configs directory like this:
Now with the sensor kicks out a trigger for a matched tweet, our rule will “fire”
That rule will can for a st2 action to run. In this case it’s a workflow. Heres a look at the YAML file.
Looking at this file we can see that it has a runner type of Orquesta. That means it’s going to run a st2 workflow, like this:
There are two tasks in the workflow. The first is to format the tweet and get the information we want, the vlan numbers. The second will send three variables over to the stackstorm-hpe-cfm pack and run an action to POST a vlan to the CFM fabric.
The YAML file tells the python what variables are coming and then the python script will match to my twitter handle.

Finally, 3 variables are sent to the hpecfm.post_vlan st2 action. So, that my friends is how you can tweet vlans into your data center fabric. Absolutely crazy!

I sense a disturbance in the force! How about you Mr. Spock?

Sub title: stackstorm sensors, what little I know about them
Sensors are what make stackstorm “event” based. They can “watch” for specific events to occur, and when they do they emit a trigger-instance. The triggers are matched to Rules and if there is a match, the rule will kick off an action, or a host of actions in what is called a workflow. A critical piece of “If This Then That” automation.

When I started my journey into stackstorm, I knew that it would take some time to get my head around all the moving parts. The Actions, Workflows, Sensors, Rules, Triggers are all different from each other and have an intertwined relationship. In this blog, we have discussed building a stackstorm pack and building actions and workflows. By their nature actions and workflows are not automation. They need something to put them in motion. That job falls to the Rule. If you want to know more about rules, then jump down and follow the link at the bottom of this post.

Let’s start our sensor discussion with a simple action. We know from earlier posts that an action needs to have a YAML file that defines the variables used by the action and a shell or python script. There are other runner types but don’t worry about them here.
Below is a simple action that writes a hyperlink to a file called index.html. Here is the YAML file.

You can see we want to run a python file when this action is called. The file is Further, we see this python application takes an argument. In this case ‘link’ with a variable type of string.

Once the YAML and PYTHON are completed and stored in /opt/stackstorm/packs/default/actions/, we need to tell stackstorm to reload. We issue the command:

st2ctl reload –register-actions

If you want to see if st2 did the right thing with your action….issue:

st2 action list –p default

This will list all the actions in the default action directory.

Now we can run this action from the command line like this:

st2 run default.write_html body=’’

Closer inpsection of the python file reveals the location where the index.html is written. /opt/stackstorm/packs/tutorial/etc/index.html. If you load the link in a browser, you should see the URL you added when you ran the action, in the browser!

OK so far, but where is the automation? That would be where the sensor comes into focus. I am going to look at the rabbitMQ sensor. It’s one I am familiar with. Let’s have a look at a very simple implementation of the rabbitMQ. Two python scripts, one a sender, the other a receiver.
This script sets up a connection and a channel. Next, we declare what queue we want to subscribe to. Finally we push the message to the channel with the basic_publish. Great run this script about a 1000 lines …all you are doing is filling up the bus with messages that it cannot deliver. If you have the tools installed you can try this:

rabbitmqadmin get queue=hello count=99

This command will show you all the messages waiting to be delivered. They stay in the queue until someone gets them!
Now we need something to listen to our queue and do something about it. We need a “sensor”!
This is where we start learning about callback. This script starts out the same and sets up a connection and a channel to communicate on. Likewise it declares what queue it want to subscribe to. Then we define the callback method. This is where we send variables to get handled by some action. In this case what gets sent to callback is printed to the screen with a preceding [X].
It’s in the ‘basic_consume where this script is consuming messages off the bus from the ‘hello’ queue. There is a parameter that when a message is on the bus, causes information to be passed to callback.
At this point, anything in the stackstorm universe can be done. Run an action, workflow, set triggers. I leave the rest up to you imagination. Which I sure is quite amazing!

So just to wrap up the rabbitMQ discussion, if you look at the bus and there are no messages, that might not be a bad thing. Messages were meant to be put on the bus….and taken off! Now you have a basic understanding of rabbitMQ, how can we apply it to the rabbitMQ stackstorm sensor? Let’s have a look.
If you follow that blue link, it will take you to where I got the code for the simple rabbitmq lab. All the rest is just some obligatory authentication and init functions to get the sensor running in stackstorm. Here the sensor learns of what queues it should watch by the information in the example file in /opt/stackstorm/configs directory. Let’s look further:
This should start looking more familiar. We are setting up a connection and a channel. Further, we declare what queues we are going to subscribe to. We may have more than one! Next, the callback, that when activated runs ‘dispatch_trigger’. Finally at the bottom is where we are consuming the queue. Just like in the example earlier. Nothing scary!
Now, to tie it all up, the trigger itself. This could really be anything, it’s functionality is described in this section. We give the trigger a name. Rabbitmq.new_message works for me. Next we add in what parameters we want to pass. In our case the queue name and the body. From our action above, that would be the hyperlink to write to the index.html file!

Once a new message arrives in our rabbitMQ queue, this rule is activated:

name: “write_url_to_index”
description: “Write the APOD URL to the etc/index.html file.”
enabled: true

type: “rabbitmq.new_message”
parameters: {}

ref: “tutorial.write_html”
link: “{{ trigger.body }}”

The trigger is a new message on the rabbitMQ bus. The trigger-instance has an action of tutorial.write_html. That would cause the action to run every time the is a new message on our rabbitMQ queue. Now thats automation!

This is a very high level discussion about a complex subject so I decided to put together a deeper dive into the technology.

So if you want to know ‘way’ more than this humble blog post….check out my stackstorm training, made just for you over on My github
Hey, it’s wellness Friday and it’s past 2 PM!