Rudder

Some implementation question:

- do we put that bundle in its own file ? (I think not, in promise.cf)
- what name for the bundle ?
- no modification in initial-promises.cf... That won"t make them converge better.

- need to remove the old BUNDLELIST variable in the technique metadata, but keep it in the code to allows migration.

Hi,

Here are my opinions on these:

François ARMAND wrote:

Some implementation question:

- do we put that bundle in its own file ? (I think not, in promise.cf)

Yes, I think we should put that bundle in it's own file. "promises.cf" is awkward because it is the only entry point for cf-agent, so basically the less there is in it, the easier it is to make code modular and use parts of it. In particular, if one day we wanted to allow Rudder to be used as "just a part" of a bigger CFEngine policy, it would be very easy to do if you just need to add this new file/bundlename to your existing inputs/bundlesequence.

- what name for the bundle ?

I propose "rudder_directives". This name implies that it should only contain user-defined Rudder directives. Any system calls we make would preferably be kept separate (either left directly in the bundlesequence, or via another intermediary bundle like "rudder_system_directives".

- no modification in initial-promises.cf... That won"t make them converge better.

Why not? We should definitely keep them as much in sync as possible. However, there aren't any user-defined directives in initial-promises (by definition) so it probably would just be similar CFEngine-level changes, and no rudder_directives bundle call.

- need to remove the old BUNDLELIST variable in the technique metadata, but keep it in the code to allows migration.

Yep.

Jonathan CLARKE wrote:

Hi,

Here are my opinions on these:

François ARMAND wrote:

Some implementation question:

- do we put that bundle in its own file ? (I think not, in promise.cf)

Yes, I think we should put that bundle in it's own file. "promises.cf" is awkward because it is the only entry point for cf-agent, so basically the less there is in it, the easier it is to make code modular and use parts of it. In particular, if one day we wanted to allow Rudder to be used as "just a part" of a bigger CFEngine policy, it would be very easy to do if you just need to add this new file/bundlename to your existing inputs/bundlesequence.

Well, so what happen to inputs ? I understand that they can be only declared in "body control sequence" (so much for modularity). And it seems that it makes little gain to output the bundlesequence if the list of dependencies is kept on promise.st (we just made more difficult to debug problem that were apparent before, like a missing dependency).

Of course, if we can make several bundle sequence part, each semantic one in its own file, and only keep something minimalist in promise.cf, I'm all in. Someone versed in CFengine can help here ?

- what name for the bundle ?

I propose "rudder_directives". This name implies that it should only contain user-defined Rudder directives. Any system calls we make would preferably be kept separate (either left directly in the bundlesequence, or via another intermediary bundle like "rudder_system_directives".

OK with that name.

- no modification in initial-promises.cf... That won"t make them converge better.

Why not? We should definitely keep them as much in sync as possible. However, there aren't any user-defined directives in initial-promises (by definition) so it probably would just be similar CFEngine-level changes, and no rudder_directives bundle call.

Well, the refactoring of all the different promise.* to make them converge is far beyond my cfengine skills, and/or may imply the need to have some templating engine in the build process. It seems to far outreached the scope of that little modification.

Again, I'm all in for that goal. It's an heresy to have "almost duplicate" code, a nether ending source of bug, and an horror to maintain, with a lot of expert knowledge (like in "expert system": a rule, with 10 000 exception, that only a system with a big database, or the history of all reason why some choice should be made, can manage).

But it seemed to be a big, hard, long task. OK, it was about the whole deduplication of promises/initial-promises. Perhaps a subpart, for promises.* only, can be made. I can't do it (in a reasonable time), thought.

So, for the inputs, we could call list defined on other bundle, like it is done for ncf.

So we could have a "rudder_directives.inputs" for that, and keep things together on "rudder_directive" file. And make the same for ncf.

That still don't make the promise.cf of initial promises and the one of technique the same, but they should be much more alike.

Applied in changeset rudder-techniques|9d7266903ad270f8a795820a50c48de1054155c5.