A key idea of the Arusha Project is to have a uniform object-oriented view of all sysadmin entities. This is the core notion that will make Arusha sysadminning a wonder to behold -- so it's important!

This documents explains the important ideas of the ARK object model. When you are ready to make some ``objects'' of your own, please consult the ARK configuration language guide.

Laundry list of "sysadmin entities"

As an aide memoire for thinking broadly about all the "sysadmin entities" we might want to manage in our uniform "object" framework, here's a list of candidates:

Hosts
Users
Packages
Purchase requests
Purchase orders
Support calls
System configurations
Vendors
Clients
Maintenance contracts
Mailing lists
Network ingress points
User environments
User roles
(More, please!)

(Of course, not all sites will be interested in the same "entities"; such things are configurable...)

Object scheme desiderata

We have a rather low-budget notion of "object-oriented". We'd just like to think about all of our sysadmin "entities" in a uniform way, and we "make them do things" (or "do things to them") by invoking their "methods". Not much more than that... So, here are some working desiderata:

Our "object scheme" must be pretty simple. Sysadmins are not, by and large, object junkies, and they (rightly) just won't use it if it's unduly obtuse.
It must be language-independent, at least in the following ways:
- The code that implements a method (e.g. `package.install()') can be written in a variety of languages, including at least Python, Perl, or /bin/sh.
- The "core Arusha APIs" could be reimplemented in Perl and/or Java (and/or ???).

A prototype-based object scheme

It is difficult to conjure up a typical class-based object-oriented design while trying to avoid over-entanglement with any one programming language.

Happily, it is possible to build a classless object-oriented framework. The best-known examples are with prototype-based languages [see: table of same]. The idea is: you make the "thing" you want by cloning a "prototype" object (which is nearly what you want), and then tweaking its methods/attributes/whatever 'til you've got what you want.

One fancy term for this is value inheritance (as opposed to `type inheritance').

Let's move instantly to a real `object'; we specify these with XML in our configuration language. This is an `unzip' package object:

<package name="unzip--5.41" xml-version="1">
<status>revealed</status>
<prototypes>
  <prototype team="sidai" name="info-zip"/>
  <prototype team="."     name="ALL"/>
</prototypes>

<assemble-source>
  <param name="PKG_TGZ_FILE">@package:ark-dirs:PKGS_SRC@/unzip541.tar.gz</param>
</assemble-source>

<compile>
  <param name="target">unzips</param>
</compile>
</package>

Here, we are saying that the unzip--5.41 package -- that's version 5.41 of `unzip' -- for the . team (shorthand for our local "site team") gets its attributes/methods first from the package sidai:info-zip "package" and then from the .:ALL "package".

For example, we might expect the info of what proto-hosts this package supports to come from .:ALL. The install-bits happens to come from sidai:info-zip, as in:

<package name="info-zip" xml-version="1" prototype="yes">
<description>
The Info-ZIP group's portable Zip and UnZip tools.
</description>

<install-bits>
  <constraint><dependency type="status"
    name="." value="installed,deployed,revealed" /></constraint>
  <constraint><dependency type="essential"
    name="." on-method="pre-install-bits" /></constraint>
  <param name="PKG_PROTO_HOST">!proxy_for.idString</param>
  <param name="MAKE">@proxy-host:MAKE@</param>
  <param name="Makefile">Makefile</param>
  <param name="prefix">!sidai_prefix</param>
  <param name="in_dir">.</param>
  <param name="target">install</param>
  <param name="make_args"></param>
  <param name="extra_make_args"></param>

  <code once-per="hosts-supported" pretendable="yes"><![CDATA[

cd $PKG_BUILD_DIR/$PKG_PROTO_HOST/$in_dir

eval exec $MAKE -f $Makefile $PRETEND $KEEP_GOING \
     	  $make_args			\
	  $target			\
	  prefix=\"$prefix\" $extra_make_args
]]></code></install-bits>
</package>

.:ALL and sidai:unzip are proto-packages (just as something like glasli1:sparc-solaris2.6) is a proto-host, both being examples of proto-things.

Note that proto-packages (e.g. sidai:info-zip) may have prototypes of their own. Prototype relationships among things (packages, hosts, etc.) form a (directed acyclic) graph [DAG]. When looking for where a thing gets a particular attribute/method, we do a left-to-right, depth-first search of the prototype DAG. (Sounds hairy, but it's kinda what you would expect...)

User's view of this object stuff

Before we go on: what does this ``object stuff'' look like to a sysadmin staring at a Unix command prompt? (NB: it is very easy to do the exact same things by scripting.) Well, things like:

% ark package build unzip--5.41
% ark host    describe slimy slinger slicker
% ark user    create --verbose bloggsj

In every case, you are asking to invoke a method on one or more objects. In the ark package line, you're invoking the `build' method of the `unzip--5.41' package (NB: for all hosts at your site).

(Here is more than you want to know about the ark tool.)

Constraints

As you saw in the unzip--5.41 example above, a method can have constraints.

Constraints can express things such as, ``This value only applies to Solaris boxes'', or ``This method should only be run after that method'', or ``This package depends on that one having been deployed'', and so on.

We leave further details to the constraints section of the ARK configuration language guide.

Naming `things'

A very cool thing about ARK prototypes is that they are used to name things...

When you refer to a ``real'' (non-prototype) thing (e.g. the ``unzip--5.41'' package), it's pretty obvious what you mean/intend. What about when you refer to a prototype thing, e.g. the ``unzip'' package from the Sidai team? Do you mean...

... that prototype package itself, plus whatever methods/attributes it inherits from its prototypes? or...
... all the real packages in the local site team that happen to inherit from that prototype package?

In the core ARK code, we always mean the latter: naming a prototype thing always expands out to the set of real things that inherit from that prototype.

Therefore, naming an `ALL' prototype thing is equivalent to naming the full list of real things at your site.

We go one step further: if a tool/method has an implicit set of things (e.g. in `ark package build ...', it is implicit what set of hosts we are building for), that implicit set is always derived from the prototype `ALL' -- now that's `site-at-a-time' thinking!

Now, blindly doing everything for `ALL' things every time can lead to madness. For example, doing `ark package unpack-source ...' (i.e. unpacking source tarballs for one or more packages) only needs to be done once per site, certainly not on `ALL' hosts, one after the other.

Individual methods, using XML data, can limit their `scope'. For example, for packages, their scope can be limited to `once-per-site' or `package-hosts' (the proto-hosts for which the package is built, e.g. `sparc-solaris2.6'). An `unpack-source' method would probably have scope `once-per-site'; a `compile' method would have scope `package-hosts'. The default scope is, of course, `hosts-specified', which in turns defaults to `ALL'.

Using prototypes for `pattern matching'

ToDo

Avoiding chaos

We have already had enough experience with Arusha ``objects'' and prototypes to know that ``inheritance spaghetti'' -- a confusing tangle of who-got-what-from-whom -- is a real possibility.

We propose a couple of defenses:

The (self-)documenting system will help (ha!). The ARK base code goes to a lot of trouble to remember the `provenance' of attributes and/or methods, and these can be accessed/printed-out. To try it out, just use the `describe' method on any basic ARK tool.
More generally, we intend for it to be possible to generate, from objects, Web pages (say) about their status, history, etc. If objects can "say" fairly clearly what they are and how they came to be that way, then that covers for the fact that the process may be quite complicated.
Use prototypes in stylised ways. We expect teams will have standard `patterns' for how they set up their prototypes; the Sidai team certainly will. If you follow one of these standard patterns in setting up your own prototypes' structure, you should be OK.
Prototypes are checked. (next section)

(Proto-)Things are checkable

Consider how this prototypes game will play out over time... Some of your prototype things -- e.g. a `sparc-solaris' proto-host -- will live forever and have fairly obvious meaning. However, you will also invent proto-things when particular needs arise (say, a `desktop-machine' proto-host...) whose exact meaning may become fuzzy and/or forgotten over time.

The Arusha solution is to associate checks (we call them `assertions'...) with all objects. We envisage assertions of two types:

Those that check that ``yes, this object is one of us''.
MAYBE: We may also do the assertions the other way 'round! For all the other proto-things in the system (which this thing does not have as a prototype...), we check that this object fails those assertions.
The are almost certainly constraints within the proto-thing space, independent of any objects. For example, if you had proto-hosts hpux-sendmail-v8 and hpux-sendmail-v9, you would have a constraint that said a host can't inherit from both.

Having a good collection of assertions on your Arusha objects helps to ensure that you stay on top of the questions of the form ``and what exactly do you mean by...?''