Instancemanager: now also handy for server setups¶

In the last few weeks loads of improvements were made to instancemanager, mainly aimed at improving instancemanager's server side story. Version 0.3 is out .

Instancemanager was originally aimed at managing your development zope instances. Starting/stopping, creating them, filling the Products/ directory, automatic quickreinstalling everything, that sort of tedious stuff. Something that's tedious is, by definition, something just begging to be rounded up, automated away and shot.

Some of the big changes and improvements:

Optparse

I now use python's standard optparse module to parse the commandline. With all those extra server-side options the homebrewn way was showing its age. Also passing along arguments to options wasn't really possible. So optparse to the rescue. It does mean changes to the way you have to call it. instancemanager start projectname is now instancemanager --zope start projectname.

There are some short options, like -z instead of --zope. And there's the shiny new multi-actions that will take away most or all of the pain of this change. instancemanager --help will show you the new syntax.

Zeo support

This is a biggie. Add a use_zeo = True to your project's config file and instancemanager will create both a zeo server and a zeo client (=zope server) for you. Way quicker when doing a restart, as the zeo server will just keep running with all your data still available. Also the solution for the real server work.

Hey, this is what instancemanager is all about: it is a bit of extra work to create zeo instances, so I normally didn't do it. Now it is only a one-line change in a config file away. Laziness incorporated.

Backup/restore

Jean-Paul Ladage added this. Backup your zope instance (incremental backup) and restore the latest backup. As is usual for instancemanager, there are sensible defaults: everything gets backed up to ~/backups/projectname/*, which is wildly open to customisation, though.

I added some more specific possibilities to a --repozo action: snapshot backups + restore, handy for taking a quick backup separate from the normal backups for use just before you muck up your instance with a new untested product. Also a forced full backup is available.

And a "sync" backup, in which you can copy/paste a running database to another instance: for instance when running a production and preview server in parallel .

Multi-actions

Your ticket to happiness. Perhaps the build-in "fresh" and "soft" commands suit you, perhaps not. They used to combine a few actions into one handy command. create, products, start, quickreinstall. If that wasn't your preferred way of doing things, you were out of luck.

Not anymore! You can have generic or per-project multi-actions. They're really just a list of things you'd pass to instancemanager on the commandline, so that's simple. It also means that you can disable the normal "fresh" and "soft" multi-actions, keeping your server instance free from accidental deletion.

The two server instances ("production" and "preview") that I deployed at philips (intranet for their research department) today only have a single "update" multi-action. Production does a snapshot backup, grabs the latest software and restarts itself. Preview copy/pastes production's database, grabs the latest software and restarts. Handy handy handy.

Special thanks to Maurits van Rees, Jean-Paul Ladage and Russ Ferriday who did a lot of work on this version.