I’ve just checked in and tagged ModiPY v1.0. This is the first version that I’m prepared to say is ready for use doing real tasks. Grab it at modipy.seafelt.com. I’m really excited about it. :)
I tested it out today running on a linux box, and using a NetApp simulator as a target host. I used a templated change that adds a volume, or series of volumes, and will remove them if the change to add them fails. It all worked nicely, adding 2 volumes, and then adding another 2 volumes if the first 2 were added successfully.
The new feature I added last night also worked: the ability to run change templates in ‘backout’ mode, which only runs the backout component of the changes. I used this to undo the change I ran initially, and it all worked perfectly! This means I can round trip the changes, applying and backing them out at will. Woo!
You can see the code I used in 2 files: The change template is etc/netapp-create-volume.change-template.xml and the configuration file I used with modipy.py is etc/netapp-provision-demo.xml.
Another really handy feature is Authoritarian Mode, which I also added
recently. It’s great for testing. In Authoritarian Mode, ModiPY asks
you if you want to run each and every command, allowing you to step
through each command in the change sequence. If you don’t type ‘y’ or
‘yes’, ModiPY will immediately stop, so if you don’t like the command that ModiPY wants to run next, you can bail out before anything bad happens. Neat, huh?
I think this last feature is particularly important for establishing trust in ModiPY itself, and also in the changes and change templates that you develop. I like to be able to test my automation carefully before letting it run in full auto mode at 2am on a Saturday when no one is around to fix something if it breaks. With this feature, I can.
ModiPY now has a bunch of useful features, including:
- Change dependency trees
- Full change templating
- Condition checking using Python expressions
- Iteration over parameter lists so change templates can use variables
- Change retry-on-fail, up to a settable maximum number of retries
- Change continue-on-fail, where failure shouldn’t stop dependent changes from happening anyway
plus a lots more.
Right now, the best way to find out what it can do is to try it out. I will attempt to write up some more doco on the wiki, but free time is at a premium during the festive season, so you’ll have to make do with reading the examples, the source code, and playing around.
ModiPY is LGPL, so you can use it for free. It spawns an exec() of a program by default, so you can combine it with ssh (as I do in the example) to perform changes to anything that speaks ssh.
ModiPY is so flexible that I haven’t really scratched the surface of what it can do yet. I’m planning to start really putting it through its paces, and I’ll try to write up my findings so you can read all about it.
This is a program I’ve wanted to write for years. It’s awesome to finally have something useful. I can’t wait to start automating change deployments like crazy. :)