Open Stack

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