headers
Will Partain | 4 Mar 2002 14:43
Picon
Picon
Favicon

updates 2002.03.04

Folks, I've just checked some stuff into CVS which I marked
as 'incomplete changes', because they are :-)  I'd advise
staying away from the CVS stuff for a day or two, unless you
ask around first...

(I have been working on the 'tidy-ark-areas' script, which
sweeps through a site's disks and clears off all the stuff
that shouldn't be there, according to the site's ARK
"source"... It's great for the adrenalin and for creating
that tidy feeling :-)

Will
Permalink | Reply | 0 comments |
headers
Shprentz, Joel [C] | 4 Mar 2002 21:54

Bug: valetc not defined in thing.py _genericDescribe

I tried the describe method on several objects.  All fail with a problem in
thing.py.  In the sample run below, I try to describe team sidai.

intelink6% ark team describe --verbose --use-deps=max sidai < /dev/null

> describe on sidai ( not done before )
  [FROM: code - sidai:team [? + 2001.09.08 08:34.19] ]
>> host: intelink6 [for hosts: ALL]

> sidai
failing code:<< 
import os,sys
VERBOSE='-v'
PRETEND=''
KEEP_GOING=''
HARD_UNDO=''
os.environ['PATH']='/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbi
n:/src/try-ark/our/bin' # don't leave PATH to chance!
OK = thing._genericDescribe()

>>
Traceback (innermost last):
  File "/src/try-ark/ark-deploy-host1/arkbase/share/ark/ark/thing.py", line
1865, in go
    exec use_code
  File "<string>", line 8, in ?
  File "/src/try-ark/ark-deploy-host1/arkbase/share/ark/ark/thing.py", line
701, in _genericDescribe
    print '%s\n\ttype:\t%s\n\tvalue:\t%s\n\tprov:\t%s\n\tdeps:\t%s\n' % (
NameError: valetc
(Continue reading)

Permalink | Reply | 0 comments |
headers
Will Partain | 4 Mar 2002 22:10
Picon
Picon
Favicon

Re: Bug: valetc not defined in thing.py _genericDescribe

Joel S catches a bug:

>   File "/src/try-ark/ark-deploy-host1/arkbase/share/ark/ark/thing.py", line
> 701, in _genericDescribe
>     print '%s\n\ttype:\t%s\n\tvalue:\t%s\n\tprov:\t%s\n\tdeps:\t%s\n' % (
> NameError: valetc

No doubt about that one :-(  _genericDescribe is kinda
useless, and has suffered bit-rot.

It will be fixed.  Thanks for an excellent report.

(If you're understanding *why* that code was run, and are
learning not to panic in the fact of python stack traces,
then you're doing great.)

Will
Permalink | Reply | 1 comment |
headers
Will Partain | 11 Mar 2002 12:19
Picon
Picon
Favicon

Re: what to do w/ hosts

Folks, another tiny rumination on the "hosts quandary"...

This is an issue of "ARK fundamentals", the "theoretical"
side of the Arusha Project.  For those of you closer to
'user' than 'developer', it's nothing to worry about :-)  I
have tried to give enough background so it is understandable
to all, though.

One of our basic theses is that sysadmin needs some extra
thinking machinery.  [Analogy: Newtonian mechanics really
needed calculus; you do could talk physics without calculus,
but life got a lot better with it.]  ARK proposes a very
simple "object model" based on what some call "value
inheritance" as that extra machinery.

We call the objects "things", and the idea is that a
sysadmin can organize his/her world around the "things" that
make most sense -- users, packages, web sites, routers,
vendors, .. anything.  These "things" can have "methods",
i.e. fields that *do* something, i.e. code gets run.

Fact: such code must be run on some host or hosts.  At
present, we have "hosts" as ARK things, but they are a bit
of a hack because of their somehow-special role.

Jonathan Hogg is leading a charge (ARK TNG) based around the
elimination of the special pleading for hosts.  I mused upon
an alternative, namely to make hosts *entirely* special,
i.e. not ARK things at all.  Daniel Hagerty hinted at
support for the latter view and, when he gets time, he may
(Continue reading)

Permalink | Reply | 2 comments |
headers
Shprentz, Joel [C] | 12 Mar 2002 00:01

Re: what to do w/ hosts

On Mon, 11 Mar 2002 at 11:19:07 +0000, Will Partain <partain <at> dcs.gla.ac.uk>
wrote:

> Folks, another tiny rumination on the "hosts quandary"...
>
> ...
>
> Jonathan Hogg is leading a charge (ARK TNG) based around the
> elimination of the special pleading for hosts.  I mused upon
> an alternative, namely to make hosts *entirely* special,
> i.e. not ARK things at all.  Daniel Hagerty hinted at
> support for the latter view and, when he gets time, he may
> say more (please do :-).

> Simply saying hosts can't be ARK things sounds draconian to
> me.  So another as-yet-unmentioned possibility is to draw
> some distinction between hosts-that-are-ARK-things and
> hosts-that-are-not.  The latter entity/ies run code for ARK
> things, but are something else (abstractly speaking).  The
> former (hosts-that-are-ARK-things) are "clean" ARK objects,
> no special pleading whatsoever.

It seems to me that some "magic" interfaces or assumptions are needed by
every computer language. Here are two elementary examples:

Where to start:
    C: main ()
       -- just another function to the compiler, but a magic
          name at runtime
    Pascal: program HelloWorld
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Hagerty | 17 Mar 2002 19:14

Re: what to do w/ hosts

 > Jonathan Hogg is leading a charge (ARK TNG) based around the
 > elimination of the special pleading for hosts.  I mused upon
 > an alternative, namely to make hosts *entirely* special,
 > i.e. not ARK things at all.  Daniel Hagerty hinted at
 > support for the latter view and, when he gets time, he may
 > say more (please do :-).

    If I may make an observation...

    Ark seems to have a bunch of code in it oriented at doing "push"
style infrastructure admining.  A lot of the problems you seem to be
having seem to stem from this world view.  I assume you've read
http://www.infrastructures.org/cgi-bin/bootstrap.cgi/bootstrap/section%5b <at> name=%22pushpull%22%5d
at some point.

    The problem of "where does this code run" is completely different
under pull style infrastructure.  In my naive "never having done real
ark work" world view, a system like this would distribute the object
model to all hosts, where the model is evaluated on each machine and a
local decision is made about whether code needs to run or not.

    Is there any reason ark seems so focused on pushing?

    As for the actual quoted matter, i'm not sure I could be said to
hold either world view.  I can tell you that the arusha view of freely
generating new objects is a sane and reasonable one.  I think with
sufficient abstraction, the concept of this object "host" is special
can be made to go away, esp given the aforementioned "pull" based view
of ark.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harlan Stenn | 17 Mar 2002 19:27
X-Face
Favicon

Re: what to do w/ hosts

IMHO one needs both "push" and "pull".

At any given time the admin can schedule a "push" and there will be times
and situations when some machines will not be able to "accept" that push.

Therefore, at boot-time and at periodic intervals, each remote host must
schedule a "pull" to see if any changes are pending.

Note that this "do I need to pull?" login does not HAVE to perform the pull
at that time - it can simply alert folks that the machine is "out of date"
and an update is needed.

H
Permalink | Reply | 0 comments |
headers
Will Partain | 17 Mar 2002 21:16
Picon
Picon
Favicon

Re: what to do w/ hosts

Daniel H writes:

>     Ark seems to have a bunch of code in it oriented at
> doing "push" style infrastructure admining.  A lot of the
> problems you seem to be having seem to stem from this
> world view.  ...

Hi, thanks for a useful interjection :-)

You're right, there is a lot of such code, but I would like
to think that simply reflects how we happened to want to do
some stuff.  You could do ARK entirely without it.  At the
ARK engine level (more basic), I would hope that (on host
'foo') that

   ark package do-it --hosts=bar wibble

is 'push' (assuming 'wibble' is a non-proxied method) and
that

   ark package do-it --hosts=. wibble

is effectively 'pull'.  That is, at the "engine level", you
can be either push or pull; we don't legislate (and my
instinct is *not* to).

On the practical Sidai packages side, my goal has been to
have all methods up to 'install' (grab the source, compile,
... 'make install') be "push"-style methods [because you do
them on a once-only ad-hoc basis], and the deploy (get it on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Will Partain | 17 Mar 2002 21:16
Picon
Picon
Favicon

Re: what to do w/ hosts

Daniel H writes:

>     Ark seems to have a bunch of code in it oriented at
> doing "push" style infrastructure admining.  A lot of the
> problems you seem to be having seem to stem from this
> world view.  ...

Hi, thanks for a useful interjection :-)

You're right, there is a lot of such code, but I would like
to think that simply reflects how we happened to want to do
some stuff.  You could do ARK entirely without it.  At the
ARK engine level (more basic), I would hope that (on host
'foo') that

   ark package do-it --hosts=bar wibble

is 'push' (assuming 'wibble' is a non-proxied method) and
that

   ark package do-it --hosts=. wibble

is effectively 'pull'.  That is, at the "engine level", you
can be either push or pull; we don't legislate (and my
instinct is *not* to).

On the practical Sidai packages side, my goal has been to
have all methods up to 'install' (grab the source, compile,
... 'make install') be "push"-style methods [because you do
them on a once-only ad-hoc basis], and the deploy (get it on
(Continue reading)

Permalink | Reply | 3 comments |
headers
Will Partain | 17 Mar 2002 21:22
Picon
Picon
Favicon

Re: what to do w/ hosts

Joel S writes:

(sorry not to have replied earlier; partly busy, partly I
agree with too much of it :-)

> The benefit of describing hosts, packages, etc. in ARK XML
> instead of a generic knowledge modeling language comes
> from Arusha's added magic--the assumptions and interfaces
> that support system administration and configuration.

Yes, and a bit of ugly stuff that Mere Mortals can
understand is better than perfection that requires brains
the size of planets...

Specific questions:

> How hard is it to add another deployment type (say FTP or NFS)?

Pretty easy, I think.  For something like the FTP side,
having 'expect' as a supported language might be cool.
Nobody's come clamoring for it yet, though...

> How hard is it for user's to represent "host down" without
> internal support?

I'm not quite sure I understand the question; but I can tell
you what I do :-) For hosts that are not yet in the game
(e.g. I'm going to build them tomorrow), I mark their
<status> as 'pending'.  For hosts that are supposed to be up
and playing (<status>active</status>) but aren't, I put, in
(Continue reading)

Permalink | Reply | 0 comments |

Gmane