Sub title: Stackstorm actions….how do I?
Since the last time we spoke we have successfully released the stackstorm pack on HPE’s external github. Funny, I thought there would be cake involved. We have had an issue submitted and worked through a couple pull requests. We’re using github to truly collaborate. I just wanted to share something interesting and valuable for you seekers just starting out. Actions and how to authorize them.
Stackstorm actions can use API calls to get information from a remote system. The first question I had was how do these actions authenticate to the host? Have you ever heard the old saying, “A little knowledge is a dangerous thing”? Well, it’s true. I had been reading the documentation up to the part I learned about st2’s datastore. The light bulb went off and I thought, “Why not just add the username and password in the st2kv.system and pass them as variables to the action (see previous post)? After running the action manually, everything worked as designed.
So I asked this question on the stackstorm-community slack channel (highly recommended) and was pointed to how Fortinet, and just about every other vendor, created their own st2 “base” action. It is a python class that gets called by every action. The idea is to only have to write the authentication once. Have I mentioned I’m learning a lot lately?
Let’s have a look at the action I worte: action.py
We start by importing the python binding for the HPE Composable Fabric Controller, followed by the base action from stackstorm. We create a python class that will become our own base action. During initialization, we look for a file with configuration parameters and we use variables defined in that file to get a token.
Let’s take a look at the YAML files.
This is just an example for the st2 user. It demonstrates what information is required for the action. The config file is the config.schema.yaml and it looks like this:
I believe this is the file for the source of the st2 pack config command
If you were to run this command: st2 pack config
Now when we run a st2 action like hpecfm.get_switches, we create a class and inherit everything known in the action.py script shown above. The one variable we need from the base action class is self.client. This variable is the token we use to authenticate with the CFM via the python binding pyhpecfm.
I could just return the list of dictionaries that is assigned to the variable switches but I am only looking for a few choice bits and I want to give them special UBAR names like I find in servicenow. After creating your first pack and prior to running it, run st2 pack config mypackname and you should be set to start having the actions do what they were designed for.
So, the mystery is solved, not sure I fully understand what I am doing but it feels good and the code works. I have to admit putting code out open source forced me to be a better developer. I am starting to use the tools they way they were meant to be used. I am collaborating and it makes you feel you are part of something bigger.
Want a new action added to the pack? Just open an issue on github!