Re: open source change management tools

Erik Melander <[email protected]> writes:

> The problem I am facing, and I most likely did not
> articulate it as well as I should have, requires a more
> high level solution.  A better question would be: "What
> tools do you use to manage and track a change workflow?".
> This change can be modifying a configuration file,
> replacing hardware, upgrading an application, or
> recommissioning a server.  ...

(This is more of an Arusha Project [http://ark.sf.net/]
message (hence the ark-dev CC), but it keys off this
interesting thread on infrastructures.

While I have the floor: as far as issue trackers go, I'm
interested in Roundup [http://roundup.sf.net/].  It's got
web and mail interfaces, and it's hackable in Python, which
I happen to be interested in.  Its design won one of the
Software Carpentry things...)

The Arusha Project (ARK) engine supports a notion of
"objects" -- the things sysadmins care about, e.g. hosts,
packages, support contracts, etc., etc -- which have
"methods" that do things.  (What objects and methods are
entirely up to you.)  So host.ipAddresses() gives a host's
IP addresses, pkg.install() might install the package,
contract.chkExpiry() might check whether a contract is
within a month of expiring, and so on.

Moreover, methods can be chained together, with
"constraints".  So a package's "install" method might depend
on its "compile" method; and a user's "delete" method might
depend on its "finalArchive" method.  By chaining methods
together, you get a "flow", faintly of the kind Erik
mentions.

Now let's think about the "flow" for the `method' "upgrade
the memory in a lab full of workstations"...  You would want
to chain together the `methods' ...

      see how much memory each lab machine has
   => call up usual suppliers and get costs
   => have a meeting to decide how much memory we might buy
   => get suppliers to provide at least final quotes
   => put order through purchasing
   => get overtime authorized for the technicians
   => advise users when lab will be unavailable
   => have technicians add in all the memory
   => run tests to make sure lab machines are still happy

Why shouldn't we support this kind of "flow" the same way we
support a package's "unpack"/"compile"/"install" flow (which
is typically entirely automated)?

Surely we just need some kind of "method" that contacts some
suitable parties (by e-mail?) and says "Let me know when
you've done that bit".  It could even do this by registering
the task with an issue tracker, and have the issue tracker
tell it when it's done -- so that the next "method" can be
started.

I like the idea of a single mechanism to describe all
sysadmin "flows", whether automated or entirely manual!  Any
thoughts, or anything I've missed?

Will


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390