Product

Device42 StackStorm Integration Pack Released

We recently released an integration pack that interfaces Device42 with StackStorm. If you are already using StackStorm in your environment, or are planning to use it, the Device42 StackStorm integration pack adds some functionality to StackStorm that will make your automation tasks even easier. If you are new to Device42, check out our growing number of other integrations as well.

[hr style=”2″ margin=”40px 0px 40px 0px”]

[separator headline=”h2″ title=”Installing the new pack”]

 

Installing the new pack is simple as can be since it’s in the official StackStorm (ST2) repo. Therefore, the installation can be accomplished using ST2’s ‘packs.install’ functionality:

 

$ st2 run packs.install packs=device42

 

 

Once installed, you only need to edit the configuration file to specify credentials & the URL of your Device42 instance, and you are off to the races. Look for the README.md file in the default packs install directory for more information.

[hr style=”2″ margin=”40px 0px 40px 0px”]

[separator headline=”h2″ title=”New ST2 Actions”]

 

The initial release of the Device42-Stackstorm Integration pack currently consists of two actions:

1) device42.device_name_list: List all devices in your Device42 instance

2) device42.suggest_next_ip: Suggest next available IP address

 

[hr style=”2″ margin=”40px 0px 40px 0px”]

[separator headline=”h2″ title=”The nitty gritty”]

 

These two actions, though seemingly simple on the surface, are chock-full-’o’-automation power. The ‘device_name_list’ action accepts as optional parameters anything from, for example, an operating system version (e.g. ‘# st2 run device42.device_name_list os=freebsd’ ), which in the example case would return all devices running the freebsd operating system, a room name, a room_id, service level, device tags, device types (physical, virtual, blade, etc), and more. This makes it simple to automate updates to, say, all servers running Windows Server 2012, or to deploy a new piece of software to all servers running CentOS. If you’ve tagged your devices according to their function, getting a list of all “web” servers to push out a new configuration file to is a breeze, too — and this is just the tip of the iceberg. Let us know how you end up using the device_name_list function — we’re curious!

 

Next, let’s talk about the ‘suggest_next_ip’ action.  When automating the build and deployment of new servers, you need a reliable source of IP addresses that aren’t in use and are on the correct subnet. An Excel spreadsheet is out of the question here — on the one hand, you’ll have a party of a time automating with that; and assuming it were possible, where does the spreadsheet get its data from?

 

Device42 is already your trusted single source of truth, and its built in, enterprise-class IPAM tools already know what subnets you are using on your network, and within those subnets, whether or not devices are on the other end of each IP. When you ask Device42 for the next free IP, due to the former, you can be certain that the IP that is returned is good to go.

 

The ‘device42.suggest_next_ip’ call too accepts a wide range of parameters. Subnet can be specified by name, VLAN, by the actual subnet in slash notation (192.168.1.0/24), and by vrf_group or vrf_group_id. In addition, if the ‘reserved_ip=yes’ flag is passed, the IP suggested becomes reserved, is marked as such within Device42, and will therefore not be suggested again. Conversely, you can leave that flag off when you are testing your script. IP suggestions will still be returned, but they won’t be reserved.

 

Questions? Comments? Drop us an email or comment on this post. We’d love to hear how you are using the Device42-StackStorm Integration pack as well as what you think of it. We also always appreciate and look forward to suggestions for expansion and improvement alike – and of course never mind the occasional compliment, either!

 

Happy Automating!

-The Device42 Team

 

Share this post

About the author