help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: actionsequence suggestion


From: Tim Nelson
Subject: Re: actionsequence suggestion
Date: Tue, 11 Jan 2005 12:55:57 +1100 (EST)

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: address@hidden
http://www.webalive.biz/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]