Re: actionsequence suggestion

[Tim Nelson]

On Mon, 10 Jan 2005, Ed Brown wrote:

> "Elegance", like beauty, is definitely in the eye of the beholder.

        Agreed :).

> Maintaining the suggested linked dependencies might make sense from a
> concurrent programming best practices standpoint, but it certainly is
> not "elegant" in my aesthetic.  My goal is not optimizing for
> performance or parallelization, it is making things easier for myself.

        Agreed (see example below) :).

> Linked dependencies means keeping track of different tags for every
> relationship; multiple tags/attributes for a given instance of an action
> when a chain of dependencies is involved, multiple files to edit to make
> changes, the possibility of broken dependencies or chains of
> dependencies, and an obfuscation of the actual sequence.
>
> If it helps you to think, or program, in terms of dependencies rather
> than sequence, just consider that a "deptag=25" automatically sets up
> dependency relationships with deptags greater and lesser than itself.

	My problem with the priority system is that you end up with 
relationships that either one or both ends of the relationship are unaware 
of.  For example, say Z depends on Y, and Y depends on X.  The priorities 
are as follows:

X: 25
Y: 50
Z: 60
W: 65

	Now, say that Y is totally unaware of Z, and decides that he needs 
to use features from W.  So he changes his priority to 70.  This breaks Z. 
If the dependency tag solution were being used, Z would automatically be 
reordered after W.  Naturally, maintaining these dependencies is more work 
than randomly picking a priority and setting it, but is, I submit, less 
work than examining all existing priorities and seeing where the new one 
fits in.

> Please don't require that I set up both ends of every relationship
> explicitly, especially when multiple levels of relationship are
> required.

	Hmm.  I see your problem.  One thing I would like (but is quite 
possibly not cfenginish enough) is the ability to have a "general" block, 
so we could do things as follows:


general:
        redhat::
                files: .....
                editfiles: ....
                shellcommands: ....

	...and be able to ensure the order of execution as specified 
above.  I think this is essentially what we're trying to achieve here with 
our priorities and dependencies.  I think it has no more drawbacks than 
the priorities system mentioned.

> Also no mention was made of backwards compatibility.  If you do away
> with actionsequence altogether, every relationship that you care about

	I wasn't thinking that we would.  I guess, though, that my 
assumption was that dependencies would take priority over the 
actionsequence.  Thinking about this a bit more, I'd add "...unless a 
lowpriority=... tag was added".

> has to be structured, per individual instance of the action, because you
> are dealing with per-action attributes.  What a nightmare.  If you do
> allow an actionsequence definition, how do you deal with conflicts, ie,
> a defined dependency opposite the defined actionsequence. Numeric
> priorities handle this easily in that the defined actionsequence only
> applies at the same priority level, actually extending flexibility in
> scheduling, rather than creating a conflict.

	Hmm.  Here's another idea I had.  The thing which probably bothers 
me the most about the "priorities" idea is the numbering.  How about the 
idea of named priorities, and then somewhere specifying the ordering of 
the priorities.  This is somewhat similar to what I'm doing now:

------------------
        actionsequence  = (
                # Miscellaneous
                files.initialchecks copy links resolve
                # Configuration changes (files must be after editfiles,
                # but shellcommands can be anywhere)
                shellcommands.config editfiles.config files.postconfig
                # Service reloads
                shellcommands.reload
                # Final checks
                files.checksumming
        )
------------------

	Note how everything on the one line has the .config class.  Maybe 
a multilayered actionsequence would be good, eg:

------------------
actionsequence = (
        initialchecks::
                files
        misc::
                copy links resolve
        config::
                shellcommands editfiles files
        reload::
                shellcommands
        checksumming::
                files
)
------------------

	My idea is that it would define the previously mentioned class for 
each action.  The meaning is a little different as I would have to add 
"misc" to the copy, links, and resolve sections.  But it would, I think, 
be a step towards achieving what both Ed and I want from cfengine 
(although the syntax could possibly be improved).  Then Ed's cfengine code 
could be written as:

------------------
actionsequence = (
        foodo::
                copy editfiles
        bardo::
                copy editfiles
)
copy:
        foodo::
                /foo  dest=/foo ...
        bardo::
                /bar  dest=/bar ...
editfiles:
        foodo::
                { /foo AppendIfNoSuchLine "Hello" }
        bardo::
                { /bar AppendIfNoSuchLine "Hello" }
------------------

	Hmm.  I think it still has the problem that Ed was trying to 
avoid, which was defining separate actionsequences.  Just as an exercise, 
I'll also solve it using my "general" idea above.

------------------
general:
        foodo::
                copy: /foo  dest=/foo ...
                editfiles: { /foo AppendIfNoSuchLine "Hello" }
        bardo::
                copy: /bar  dest=/bar ...
                editfiles: { /bar AppendIfNoSuchLine "Hello" }
------------------

	In fact, if you allowed file context to carry over, you could have 
something like:

------------------
general:
        foodo::
                setfile: /foo
                copy: ...
                editfiles: { AppendIfNoSuchLine "Hello" }
        bardo::
                setfile: /bar
                copy: ...
                editfiles: { AppendIfNoSuchLine "Hello" }
------------------

        ...or even:

------------------
general:
        sub     dofile($file)
                copy: $file dest=$file ...
                editfiles: { $file AppendIfNoSuchLine "Hello" }
        endsub
        foodo::
                dofile(/foo)
        bardo::
                dofile(/bar)
------------------

        I'm sure that isn't cfenginly, though.

	Incidentally, before I forget, is there any possibility that 
cfengine will ever be rewritten to run on Parrot?  For those who haven't 
been following Parrot, it's the common platform (think JVM or .Net) which 
is going to be the backend for Perl6, Perl5, and probably also the other 
scripting languages (Python, Ruby, and a bunch of others; Haskell and 
Prolog have been talked about).  If we went this way, and did things 
right, we'd be able to embed any of these languages in cfengine, or embed 
cfengine into any of these languages, and we'd also have their *huge* 
libraries of pre-written functions on which to call.  We'd also have 
cross-platformness built in :).

        :)

--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, 
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/