Re: Re: --hosts=... semantics ?

Hmmm... which thing the method should be attached to and when it's
called was the hazy bit in my mind. One idea that springs to mind is
to have the "pre-command" method in the package thing and have it
called before each "step" of the process. It might then look like
(insert standard syntax disclaimer):

  sidai/packages/ALL--ALL.xml:

  <pre-command><code language="python">
    if constraint and (not constraint_hosts) and (host not in hosts):
      constraint_hosts = team.auto_satisfy_map[command]
  </code></pre-command>

By which I roughly mean: if I'm about to execute 'command', and this
is to satisfy a constraint, and the user didn't explicitly specify the
allowed constraint hosts, and the host I'm on isn't in the list of
hosts originally specified, then lookup the "auto-satisfy-map" with
the name of the command to see what hosts we're allowed to execute on
and continue. The normal ark code would then check to see if the host
is in the new list of constraint hosts.

This assumes that the code for the command will fail if it's on the
wrong host rather than the constraint collection code failing before
even trying to execute a command on the wrong host.

Alternatives include:

* Having the pre-command in the package thing but only executed once
  before running the "main" package command invoked on the command
  line. Can still specify package specific policy. Problem: you don't
  know what the constraints are yet, so you can't do
  constraint-specific lookups like the one I do in the example above.
  

* Having the pre-command in the host thing and executed before each
  invocation of a command on a package on that host. Can do
  constraint-specific stuff and can specify by-host policy - bypassing
  the need for my "auto-satisfy-map" since you could just define the
  pre-command on your compile host prototype(s) to say "go ahead and
  compile, I don't care".

* Having the pre-command in the team thing and executed once before
  running any command of any type on any thing. Problem: you can't do
  anything thing-specific so you're likely to have a bunch of ugly
  nested if statements.

Perhaps the right location is "E) all of the above", since if it's not
there you just carry on regardless. i.e., try calling the team
pre-command before doing anything, then try the package pre-command
before invoking a method of a package, then try the host pre-command
before running any code on a particular host.

Is this constraint functionality cross-over enough to just pick a
mechanism and put it straight into ark though? Am I suggesting
something too generic and woolly?

Have I just had too much coffee again this morning? ;-)

Jonathan

--
Jonathan Hogg, Web Development and Support, DB Equities Research London
Desk: +44 20 7547 1543, Mobile: +44 7976 614338


---------------------------------------- Message History ----------------------------------------


From: Will Partain <[email protected]>@lists.sourceforge.net on 19/03/2001 16:57

DELEGATED - Sent by:     [email protected]


To:   [email protected]
cc:
Subject:  [Ark-dev] Re: --hosts=... semantics ?


Jonathan wrote:

> OK [I'm almost done, honest ;-)]. Here's one for you Will: add in
> hooks to the host (or team?) thing called 'pre-command' and
> 'post-command' that allow people to specify their own mechanisms for
> this sort of thing and then pick a reasonable one for sidai.

Thanks for all that yummy stuff!  Just a quick question for
now... Does the 'pre-command' go with

    /our/bin/ark package reveal ...

(i.e. assoc w/ the method `reveal'), or

    /our/bin/ark package ...

(i.e. assoc w/ the thing `package') or

    /our/bin/ark ...

(neither of those)?  An example, perhaps...

Will

PS: Exercise for the reader - some or all of the above can
be implemented in the current (i.e. "ARK2") framework; write
an example :-)

_______________________________________________
Ark-dev mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/ark-dev



--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.