Re: Trying ARK feedback

> Want to run (Sidai-style) ARK stuff on one host?  OK, you
> gotta tell ARK about it; something like...
> 
>    <host name="slicker" xml-version="1">
>    <status>active</status>
>    <prototypes>
> 	<prototype team="." name="sparc-solaris" />
>    </prototypes>
>    <ip-addresses><list>	<item>130.209.242.51</item>
>    </list></ip-addresses>
>    </host>
> 
> I count about 4 small pieces of info.

Yes, 4 small pieces of info in 8 lines, surrounded by hair.  It's one thing
to have this in a file that I sometimes need to look at, and it's another
thing for a Newbie to have to figure out what really needs to be changed and
then do it for some number of hosts.

> (As I showed yesterday, if you needed to create a whole bunch of those, a
> script could chomp through them pretty fast.)

And this would be fine!  I just need to get it going...

> OK, we've also said, "And it's one of our Suns running
> Solaris" (<prototype team="."  name="sparc-solaris" />).
> You gotta say what that means:
> 
>    <host name="sparc-solaris" xml-version="1" prototype="yes">
>    <description>
>    SPARC hardware running Solaris 2.x or later
>    </description>
>    <prototypes>    <prototype team="sidai" name="sparc-solaris" />
> 		   <prototype team="." 	name="ALL"		/>
>    </prototypes>
>    </host>
> 
> That says: inherit whatever the Sidai sparc-solaris
> proto-host has to say (which is usually where particular
> programs are located).  If you don't want to know/use that
> stuff, don't use the prototype.

Think "time".  I'm busy, and the folks who will want to use this are busy.
(I think) they want this to be easy, and if there's a steep initial learning
curve they'll just give up.  If the setup is difficult, how easy can it be
to use/upgrade?

For example, I don't see an obvious "roadmap" that tells me what I need to
do to get up and running.

I see webpage/*.txt stuff that isn't really .txt files.

I find the try-ark stuff and I can make that work.  I found an email message
from Will that is starting to walk me thru the steps to get this enabled in
a production environment and I'm still slogging thru it.  I haven't found
"better" instructions, and it would make my life Lots Easier (and I bet this
would be true for all new users of the package) if the bootstrap procedure
was SIMPLE.

For example, it wouldn't be so bad if the stuff stays in .xml format if there
is an "easy" and clean way to edit the info.  I'm talking about a GUI (ugh)
or a script or emacs or webpage or ...

At some level, there really has to be an automated way to bootstrap this
puppy.  And there needs to be some way to easily maintain it, which means
the info needs to be "changed" in *1* place only, and that info must be
automatically propagated to the places that need it.

> We've also said: that we have our own team's ALL proto-host
> as a prototype; that is:
> 
>    <host name="ALL" xml-version="1" prototype="yes">
>    <description>
>    Any host at all at glasli1
>    </description>
>    <prototypes>
>      <prototype team="sidai" name="ALL" />
>    </prototypes>
>    
>    <domainname>dcs.gla.ac.uk</domainname>
>    
>    <gateway>130.209.240.48</gateway>
>    
>    <name-servers><list>
>      <item>130.209.240.49</item>
>      <item>130.209.240.50</item>
>    </list></name-servers>
>    
>    <ARK>
>    <string>@team:ark-dirs:OUR@/bin/ark</string>
>    <constraint><dependency type="optional" name="arkbase" /></constraint>
>    </ARK>
>    
>    <!-- I've snipped out lots of stuff -->
>    </host>
> 
> That's where we pick up "stuff that's true about all of our
> hosts but perhaps not anyone else's".
> 
> As far as I can tell, every individual "fact" is being
> recorded in exactly one place; can't do better than that,
> can we :-?

This works then, but there are other places where the info appears in
apparently more than one place - things like version numbers of packages
needed for bootstrapping, directory paths, etc.

> Yes, we have the huff-and-puff verbosity of XML, but that's
> the price of tagging along (sorry...) with a standard.  At
> least it's conceptually simple.

And if we can come up with a clean/simple way to specify the XML info, we
should use it.  Ideally, we should be able to generate this file from the
XML info, and then "prove" the info by regenerating the XML info and
comparing it to the originals.

Sort if like the progress being made on gen-sidai-hosts.

> The complexity of your hosts' prototype structure and what
> you choose to put in all of that is up to you.  You don't
> have to record all this stuff if you don't care about it and
> aren't going to use it.  Ditto packages.  Ditto users.
> Ditto anything else you feel bothered to record in this way.

Agreed, and still somebody has to decide what they need and what they don't,
and what the various ark/sidai/glasli/whatever teams actually do for them.

> I've spent about 10 minutes on the glasli1 hosts' structure
> over the life of the entire Arusha Project.  I may be
> missing something (please tell me!), but I'm basically
> baffled how this stuff could be a killer.

You wrote it and understand how it works.  There is a Lot of stuff here, and
some of it is duplicated, and there isn't enough documentation on how to
"get going" and the tool is powerful enough to cover Lots of ground which
will only make the learning curve steeper.

I'd really like to see "ark" be a script that is self-bootstrapping.  In
other words, it could/should have a way to make sure it can download,
compile, and install python, pyxml, ersh, and whatever else it needs to "get
going".  This will also solve the "new host running a new OS" problem.

Just my thoughts on where I'd like to see this go.

H