On 20.06.2017 17:27, Michał Jastrzębski wrote: > On 19 June 2017 at 06:05, Doug Hellmann <d...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev