Rudder

Should OUTPTAH follow the same logic as TML ? (nothing specified put the file in techniqueName directory) ?

My bad I thought there was an OUTPATH in TML

Here, we have a decision to take: either files in <FILES> are "tracked" by Rudder (or part of Rudder internal boudaries) or not.

So, what does I mean here? I mean does updating a file is observed by Rudder (and MUST be observed, always), or does such a file is external and can't be observed (or even if it can, it is not mandatory). (this comment is also linled to http://www.rudder-project.org/redmine/issues/7376#note-5)

The main practical difference is about who is responsible to see that the file changed and that every node copy of the file should be updated. If the file is external, Rudder can't do it (not always, at least), and if internal, it MUST do it.

My analysis is that as long as the file copy is part of the promise generation process, it must be internal, and basically it is a part of what defined the technique and must follows the same requirement as a template.
If so, it's quite easy to know how the file is in Rudder system boundaries: it's commited in our configuration-repository. And an update is always observable via a git diff.

Of course, there is drawbacks: for one, files must be in the git, with all implied by tha (binaries are going to waste space in the repo, user must git add/git commit, etc).

Note that is would be mandatory for a "API" kind of resource, if such one existed, to be external (and so, it must be the nodes which have the update logic of such a resource).

What do you think ?

François ARMAND wrote:

If so, it's quite easy to know how the file is in Rudder system boundaries: it's commited in our configuration-repository. And an update is always observable via a git diff.

This part can be relaxed and we can just look at the last know file modification time to observe an update. That take care of the binaries problem, but on the other hand give us less control about what changed. That can be what is expected by a user.

An other point: it can be very suprising for an user to have a file versionned on git, but to use the file content available on the FS and not on the last commit. I'm thinking at that especially for ncf techniques, which are expected to use the <FILE> tag, are commited on "configuration-repository" git, but that content won't be used.
On the other hand, if we have a different for file under coniguration-repository than on other parts of the FS, it's complete madness. So that would mean to tags, one for "file in git", and other for "file in fs"... Which is barelly clearer...

So, not sure about what is the best.

Applied in changeset rudder|c90a092e0db88d410ac04bfba1c80076ce1a8447.

we are missing an option to add it in the input list, so files are not taken into account

Documented in http://www.rudder-project.org/foswiki/Development/TechniqueXML