[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: tim.nelson@webalive.biz
http://www.webalive.biz/
- Re: Order of Execution, (continued)
- Re: Order of Execution, Brendan Strejcek, 2005/01/05
- Re: Order of Execution, Christian Pearce, 2005/01/05
- Actionsequence as a top level section, Chip Seraphine, 2005/01/05
- actionsequence suggestion, Ed Brown, 2005/01/06
- Re: actionsequence suggestion, Mark . Burgess, 2005/01/06
- Re: actionsequence suggestion, Tim Nelson, 2005/01/10
- Re: actionsequence suggestion, Brendan Strejcek, 2005/01/10
- Re: actionsequence suggestion, Ed Brown, 2005/01/10
- Re: actionsequence suggestion, John Borwick, 2005/01/10
- Re: actionsequence suggestion, Ed Brown, 2005/01/10
- Re: actionsequence suggestion,
Tim Nelson <=
- Parrot, cfengine, and embedded languages, David Douthitt, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Mark . Burgess, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Pe5kyTac0, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Christian Pearce, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Tim Nelson, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Christian Pearce, 2005/01/12
- Re: Parrot, cfengine, and embedded languages, Tim Nelson, 2005/01/12
- Re: Parrot, cfengine, and embedded languages, Christian Pearce, 2005/01/13
- Re: Parrot, cfengine, and embedded languages, Tim Nelson, 2005/01/13
- Re: Parrot, cfengine, and embedded languages, Tim Nelson, 2005/01/11