Sysadmin Work
ISconf clearly defines that it is meant to automate system administration
work for a few simple reasons. First, there is usually a strong division
in responsibility between the sysadmins and the application admins, such that
it is often difficult or impossible for the sysadmins to convince the application
admins use provided automatation tools. Second, many applications are programmed
in such a way that they are difficult and sometimes even impossible to administer.
However, in cases where it is technically and politically possible, applications
should also be automated using ISconf. Artificial lines should not
be drawn just because they are convenient, but one should also not let
individual applications, which after all can just be dumped to tape, stop
one from taking advantage of as much automation as possible.
Network of Unix Machines
ISconf has only been used to manage Unix machines, but there is actually
no reason why it couldn't manage other types of machines. Any machine which
can be controlled completedly programmatically can be managed using ISconf.
Lies and Damn Lies
Unfortunately, the world we present isn't quite as rosy as it looks.
There are a number of problems with the system we have come up with:
-
The current typing system still isn't always deterministically ordered
If you create a server as a single type, instantiate it entirely, and then
add a second existing type, with it's own list of ordered steps, to the host,
then on that host those steps will not be executed in the order of their
timestamps, but on any subsequently built hosts, all work will be done
in the order of the timestamps, and thus in a different order.
The only real way to solve this problem is to change the type assignment process.
Instead of storing the timestamps with the type, the timestamps should be
stored with the host and created when a work chunk is associated with a
host, not when the chunk is associated with the type. There is no planned
method of making this change right now.
-
We currently don't have a standard method of creating atomic work
chunks
Even though atomic work chunks are so fundamental to our system, we haven't
been able to come up with a sufficient method of guaranteeing the atomic
nature of all our code. Really, the difficulty is the atomicity plus the
state maintenance. Look for more information regarding potential solutions
in the documentation for Version 4, or possibly
a separate writeup.
-
We currently don't have sufficient code-sharing mechanisms in place
At the present, each team is an island. There is no standard within
ISconf to facilitate code-sharing. This is one of the major goals of
Version 4
-
Separation between code and data isn't as good as it could be
Currently the make files are required to contain both the code to perform
any work and the data describing what work to do. Significant amounts of
research are being done towards finding both short-term and long-term
solutions to this problem.
-
Deterministical ordering can be broken by the CONTEXT system
Work chunks which require a reboot will only be executed when the system
is running in BOOT context, usually during a reboot. Because of this,
this type of work chunk will sometimes be executed after work chunks which
actually appear later in the ordered list. For instance, if you add
two work chunks, first one requiring a reboot and then one which does not,
and then run ISconf immediately on the host, then chunk which
does not require a reboot will execute immediately even though the
reboot chunk is before it in the list and has not executed yet.
There is no known solution to this problem at this point.
-
As long as you use any file management methods such as rsync or cvs,
your systems cannot be managed deterministically
If you are using something like rsync to manage any files on your
system, then changes in those files will not happen deterministically.
For instance, if you build a system with a services file which does
not list the NetBackup services, and then use rsync to load a
services file which has those services, if you build another host like
this one, that host will immediately have the services file with the
NetBackup services.
This isn't usually a problem, but it does kind of break the rules.
The real solution to this problem is to use work chunks to manage all
of your files, and not to use cvs or rsync to do so.