Feature Request: standard template location

[nickanderson]

If we are bundling a template with a sketch we should seed that template to a well known directory inside masterfiles. If we don't provide the guide rails people are likely to edit the templates included with the sketch. I think altering the distributed sketch can make upgrades fiddly.

More than a feature I guess this is a style guide thing.

Penny for your thoughts?

[zzamboni]

Thanks for the feedback. It probably makes sense to install certain types of components under different directories, for example modules under /var/cfengine/modules, templates under /var/cfengine/templates, and so on. Files in the manifest can already have metadata associated with them, so it should be possible to do special handling.

But then the eternal question of package management comes up: what to do when you install a new version of the sketch, but the installed copies of the files have been modified by the user? There's no right answer, so we need to come up with scheme for handling it.

On Feb 12, 2013, at 11:07 PM, Nick Anderson [email protected] wrote:

If we are bundling a template with a sketch we should seed that template to a well known directory inside masterfiles. If we don't provide the guide rails people are likely to edit the templates included with the sketch. I think altering the distributed sketch can make upgrades fiddly.

More than a feature I guess this is a style guide thing.

Penny for your thoughts?

—
Reply to this email directly or view it on GitHub.

[nickanderson]

My thought was sketches shouldn’t be modified by the consumer. If a sketch distributes a template, or a module and a user wants to modify it I don't think we want them to modify the sketch files themselves.

I was thinking something like this.

seed well known directories (templates, modules) with files distributed with the sketch. (body copy_from seed_cp)

And sketches should use the well known directories for default values. This leaves you with the distributed file to diff against and provides something for the user to edit to taste if desired.

I think the sketch upgrade/warnings from issue #234 come into play here as well. If a module or template has been updated we should warn the user, it would be neat if we could then detect if they have modified the seeded module or template notify them one way or another ("We noticed you haven't modified the default template, would you like to upgrade to the new version here is a diff" and offer automatic upgrade/replacement or "We noticed that you modified the default template. You may want to review a diff of the default file blah ..." and let them sort the differences themselves).

I could probably be convinced of a different approach but I think this is a general area we need to improve. I see it as kind of an extension on the default policy set and providing scaffolding with the framework.

[tzz]

There's no way templates should be outside the sketch directory itself. But also sketches should allow customizing the template directory, in general.

(I prefer to inline templates because it sidesteps this issue.)

Modules are trickier but I'd prefer to keep them with the sketch as well.

[nickanderson]

When sketches execute modules, where do you think the modules should be executed from? From within the sketch itself, or should the sketch be seeding the registered modules directory WORKDIR/modules?

Since the usemodule function https://cfengine.com/manuals/cf3-Reference#Function-usemodule looks in WORKDIR/modules do you not think that sketches should just look there by default, with the default module name if none is otherwise specified? If the default module doesn't exist there, then shouldn't the sketch seed it?

If this is the accepted default then we can even have a seed_files_from_to bundle in a design-center library to handle seeding files from sketchname/modules to WORKDIR/modules and then the same thing for sketchname/templates and WORKDIR/templates.

I can't seem to find it right now, but from within policy itself isn't there a bug related to determining a the full path of the filename a promise is in? Either way we need this functionality to work so that the policy itself is not dependant on cf-sketch to fill things like bundle_home.

[tzz]

The problem is, you're maintaining two disparate locations when you have a sketch module installed under WORKDIR/modules. For a site it makes sense; for a DC repo it doesn't. So I'd rather use an absolute path through commands promises as in https://cfengine.com/manuals/cf3-Reference#module-in-commands than usemodule. It's the same reasoning as with templates, and should also be customizable.

Any bug with this.promise_filename as specified in https://cfengine.com/manuals/cf3-Reference#Variable-this_002epromise_005ffilename can be fixed. If we commit to a bad design, we can't fix that. I'm OK with making DC depend on 3.4.3 or whatever version has what we need.

[nickanderson]

I understand the extra work with maintaining two separate locations. The only reason I am stuck on the seed idea is because I think if there is a default template that is used and someone wants to customize it, the path of least resistance is to edit the default file distributed within the sketch (which I think should be discouraged). But maybe I am making it more complex than it needs to be. Or maybe I am solving a problem that doesn't exist. I'll think about it some more.

[tzz]

The problem you're describing definitely exists. I don't want to solve it by making every sketch take a template+module path parameter, that would be tedious. I also don't want to make it magical in any way.

How about having a template path override in the run environment? Relating to our discussion in #253 I think there's a strong use case for "the default templates live under the sketch installation directory , but you can override their path as needed." Same with modules. It feels external to the sketch operation, like it's not something you want to configure explicitly with the sketch itself, and it also feels like something users will want to override per DC runfile, not per sketch.

[nickanderson]

I don't know. I don't think we have to make a decision right now.

[tzz]

Take a look at CFEngine::dclib, specifically the eu bundle:

# environment utilities, shortened for convenience
bundle agent eu(runenv)
{
  classes:
      "$(vars)" expression => "default:runenv_$(runenv)_$(vars)";
      "not_$(vars)" expression => "!default:runenv_$(runenv)_$(vars)";

  vars:
      "vars" slist => { "@(default:$(runenv).env_vars)" };
      "$(vars)" string => "$(default:$(runenv).$(vars))";

    activated.not_test::
      "path_prefix" string => "", policy => "free";
      "exec_prefix" string => "", policy => "free";
      "show_prefix" string => "", policy => "free";

    activated.test::
      "path_prefix" string => "/tmp", policy => "free";
      "exec_prefix" string => "/bin/echo ", policy => "free";
      "show_prefix" string => "/bin/grep . ", policy => "free";
}

Could a template path be built into this mechanism, based on some data from the run environment? It feels like a clean solution.