Open Stack

On 20.06.2017 17:27, Michał Jastrzębski wrote:
> On 19 June 2017 at 06:05, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Michał Jastrzębski's message of 2017-06-16 15:50:54 -0700:
>>> So I'm trying to figure out how to actually use it.
>>>
>>> We (and any other container based deploy..) will run into some
>>> chicken/egg problem - you need to deploy container to generate big
>>> yaml with defaults, then you need to overload it with your
>>
>> The config schema file (the "big YAML with defaults") should be part of
>> the packaged software, so the deployment tool shouldn't need to generate
>> it unless you're handling drivers that are not included in tree.
> 
> Right that's what I was missing, I guess we can generate these during
> buildtime without big issues, then it will be embedded into container,
> shouldn't be too hard change and would work for both source and
> binary.
>>> configurations, validate if they're not deprecated, run container with
>>
>> It doesn't do it today, but the thing that converts the input data to
>> the INI file could automatically translate old option names to their new
>> names.
>>
>>> this ansible role (or module...really doesn't matter), spit out final
>>
>> Why does the config file need to be generated inside a container?
> 
> Outside of container you don't have oslo or nova (python libs), so to
> get access to these you need to do it inside container.

That could be another container I suppose. Like those containers used
for build deps, there could be as well a container for config management
deps. Docker multi-stage [0] could help to achieve that smooth, w/o
impacting the service containers.

> 
>>> confg, lay it down, deploy container again. And that will have to be
>>> done for every host class (as configs might differ host to host). Imho
>>> a bit too much for this to be appealing (but I might be wrong). I'd
>>> much rather have:
>>> 1. Yaml as input to oslo.config instead of broken ini
>>
>> I'm not opposed to switching to YAML, but it's a bit more involved than
>> just adding support in the parser. All of the work that has been done on
>> generating sample default files and documentation needs to be updated to
>> support YAML. We need a migration path to move everyone from INI to
>> YAML. And we need to update devstack and all of its plugins to edit the
>> new file format. There are probably more tasks involved in the
>> migration. I'm dealing with a couple of other projects right now, and
>> don't have time to plan all of that out myself. If someone else wants to
>> pick it up, I can help with reviews on the spec and code changes.
> 
> Switching is a big no, everyone would hate us with emotion pure as
> mountain spring water. It's to support both at same time, which makes
> it slightly more complex. We could make full switch after few releases
> of deprecation I guess. Anyway, agree, lots of work.
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando