[openstack-dev] [kolla] better solution for the non-ini format configure file

Steven Dake (stdake) stdake at cisco.com
Fri May 6 13:21:24 UTC 2016

On 5/5/16, 4:52 AM, "Paul Bourke" <paul.bourke at oracle.com> wrote:

>TL;DR keep globals.yml to a minimum, customise configs via
>It seems right now the "best" approach may be to tokenise variables as
>required. This is the approach we currently use in Oracle. There are two
>other approaches I can think of available to us:
>1) The overwrite mechanism as Jeffrey mentioned
>2) Make the merge_configs script modular so it can handle more formats
>than just ini
>The problem with 1) is that it is heavy weight for the Operator who
>wants to just customise one or two variables such as WEBROOT. Now they
>have to copy and maintain the entire config file.
>The problem with 2) is that I feel it's a burden on us to write and
>maintain code that can merge many different file formats. It could be
>done, though may potentially be outside the scope of the project.

I'm a fan of this option.  It is not outside the scope of our project to
maintain fundamental building blocks to execute various parts of our
software stack (in this case reconfigure).

>The tokenisation approach is unfortunately against what is described in
>"Kolla¹s Deployment Philosophy"[0] though the reality may be that this
>approach is the most Operator friendly. In regards to concern of
>globals.yml growing unmanageable, I feel globals.yml is overused and
>should only store the bare minimum. Service specific variables should be
>kept within their own role files (e.g. ansible/roles/horizon/defaults),
>and then documented which are available for tweaking via top level
>host_vars/group_vars. This is standard practice in other Ansible roles
>I've come across.
>[0] http://docs.openstack.org/developer/kolla/deployment-philosophy.html
>On 04/05/16 16:28, Mauricio Lima wrote:
>> I agree with your approach Jeffrey, although this is not ideal, this is
>> an approach already used in kolla.
>> 2016-05-04 12:01 GMT-03:00 Jeffrey Zhang <zhang.lei.fly at gmail.com
>> <mailto:zhang.lei.fly at gmail.com>>:
>>     Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to
>>     the globals.yml file.
>>     Because there is no chance to change the horizon/apache configure
>>     file now.
>>     The root cause is that: Kolla do not support non-ini format
>>     configure file. for the
>>     ini-format file, we use a merge_config module[1] to merge all the
>>     found file. But it
>>     will be not work for configure file for apache, rabbitmq and so on.
>>     I would like to the current merge_config implementation. It is
>>     directly and easy to use.
>>     Not like the puppet, we have to remember the variable name defined
>>     in the module. we have
>>     no chance to add some user-defined variable.
>>     Export the variable to global is very bad and ugly. It will became a
>>     disaster when more
>>     and more variables is exported.
>>     So we should catch up a better solution to handle the configure
>>     One solution I have is use overwrite mechanism. for example when
>>     there is a file in
>>     /etc/kolla/config/apache.conf, it will overwrite the templates in
>>     the roles. But this
>>     is still not ideal.
>>     Any body has better solution?
>>     [0] https://review.openstack.org/306928
>>     [1]
>>     --
>>     Regards,
>>     Jeffrey Zhang
>>     Blog: http://xcodest.me <http://xcodest.me/>
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list