Open Stack

Excerpts from Steve Baker's message of 2014-04-15 16:30:32 -0700:
> On 15/04/14 13:30, Clint Byrum wrote:
> > Excerpts from Ben Nemec's message of 2014-04-14 15:41:23 -0700:
> >> Right now the os-*-config projects default to looking for their files in 
> >> /opt/stack, with an override env var provided for other locations.  For 
> >> packaging purposes it would be nice if they defaulted to a more 
> >> FHS-compliant location like /var/lib.  For devtest we could either 
> >> override the env var or simply install the appropriate files to /var/lib.
> >>
> >> This was discussed briefly in IRC and everyone seemed to be onboard with 
> >> the change, but Robert wanted to run it by the list before we make any 
> >> changes.  If anyone objects to changing the default, please reply here. 
> >>   I'll take silence as agreement with the move. :-)
> >>
> > +1 from me for doing FHS compliance. :)
> >
> > /var/lib is not actually FHS compliant as it is for "Variable state
> > information". os-collect-config does have such things, and does use
> > /var/lib. But os-refresh-config reads executables and os-apply-config
> > reads templates, neither of which will ever be "variable state
> > information".
> >
> > /usr/share would be the right place, as it is "Architecture independent
> > data". I suppose if somebody wants to compile a C program as an o-r-c
> > script we could rethink that, but I'd just suggest they drop it in a bin
> > dir and exec it from a one line shell script in the /usr/share.
> >
> > So anyway, I suggest:
> >
> > /usr/share/os-apply-config/templates
> > /usr/share/os-refresh-config/scripts
> >
> > With the usual hierarchy underneath.
> +1, but might I suggest the orc location be:
> /usr/libexec/os-refresh-config/*.d
> 

Good catch. I had not read the latest draft of FHS 3.0, and indeed
libexec is included. Seems daft to base on 2.3 if 3.0 is likely to be
released this summer.

> > We'll need to continue to support the non-FHS paths for at least a few
> > releases as well.
> >
> Instead of supporting both paths, how about the orc and oac elements set
> OS_REFRESH_CONFIG_BASE_DIR and OS_CONFIG_APPLIER_TEMPLATES to
> /opt/stack/... until tripleo is ready to switch? With some prep changes
> it should be possible to make the flag-day change to require only
> changing the value of these env vars in tripleo-image-templates.
> 

I'm not worried about TripleO. I'm worried about all the other users who
may be relying on the old defaults. I think the proper way to handle it
is something like this:

if os.path.exists(old_templates_dir):
    logger.warn("%s is deprecated. Please use %s" % (old_templates_dir, new_templates_dir))
    templates_dir = merge_dirs(old_templates_dir, new_templates_dir)

We may be an 0.x release, but I think this is straight forward enough
to support being gentle with any users we don't know about.