Re: actionsequence question

[Brendan Strejcek]

Chip Seraphine wrote:

> My cfagent.conf imports a file (call it cf.import). I want a copy
> action to be perfomed prior to the groups section of cf.import
> firing. Is there a way of doing this outside of putting the copy in
> update.conf? It seems currently that the groups: stuff in cf.imports
> fires before the copy: section of cfagent.conf.

It appears from my experiments that all the groups are defined before
any actions are carried out (assuming the class is registered in
AddInstallable). In fact, it seems that the aggregate groups section,
after all imports, fires before any other action, imported or not.

To illustrate:

# begin cfagent.conf
  import: import1.cf import2.cf
  control:
    actionsequence = ( shellcommands )
    AddInstallable = ( asdf )
  shellcommands:
    !asdf:: "/bin/echo cfagent.conf asdf is not set"
    asdf:: "/bin/echo cfagent.conf asdf is set"
# end cfagent.conf

# begin import1.cf
  control: actionsequence = ( shellcommands.import1 )
  shellcommands:
    import1.!asdf:: "/bin/echo import1 asdf is not set"
    import1.asdf:: "/bin/echo import1 asdf is set"
# end import1.cf

# begin import2.cf
  groups: asdf = ( openbsd )
  control: actionsequence = ( shellcommands.import2 )
  shellcommands:
    import2.!asdf:: "/bin/echo import2 asdf is not set"
    import2.asdf:: "/bin/echo import2 asdf is set"
# end import2.cf

The result is:

  $ cfagent -qK
  cfengine::/bin/echo cfage: cfagent.conf asdf is set
  cfengine::/bin/echo impor: import1 asdf is set
  cfengine::/bin/echo impor: import2 asdf is set

If asdf is not registered in AddInstallable, cfagent ignores lines that
reference asdf (until it becomes defined).

  $ cfagent -qk # same policy as above, save no AddInstallable
  cfengine::/bin/echo impor: import2 asdf is set

> (My motive is that I am trying to limit my update.conf as much as
> possible.)

My workaround would be to not use the groups section and instead wrap
your class definition in a module, if you truly need this behavior. Then
you could place this module in some actionsequence and be sure that the
ordering will be correct.

All tests were done with cfengine 2.1.3 on openbsd 3.4.

Is there a reason based on convergence that this design was chosen? It
seems counterintuitive.

-- Brendan