On 04/15/2014 10:32 PM, Clint Byrum wrote:
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.
Okay, thanks for the good suggestions. I've proposed a couple of
changes to switch the default and still support the old defaults.
I did not change the tools to pull from both directories if they exist
because I thought that could potentially be confusing if someone had
stale files in the old location and was expecting to use the new
location. I think it's less confusing to make the switch
all-or-nothing. Plus it makes the code change less complex :-).
https://review.openstack.org/#/c/89667/
https://review.openstack.org/#/c/89668/
Thanks.
-Ben
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
