[openstack-dev] [deployment][kolla][openstack-ansible][openstack-helm][tripleo] ansible role to produce oslo.config files for openstack services

Flavio Percoco flavio at redhat.com
Mon Jun 26 13:37:25 UTC 2017


On 15/06/17 13:06 -0400, Emilien Macchi wrote:
>I missed [tripleo] tag.
>
>On Thu, Jun 15, 2017 at 12:09 PM, Emilien Macchi <emilien at redhat.com> wrote:
>> If you haven't followed the "Configuration management with etcd /
>> confd" thread [1], Doug found out that using confd to generate
>> configuration files wouldn't work for the Cinder case where we don't
>> know in advance of the deployment what settings to tell confd to look
>> at.
>> We are still looking for a generic way to generate *.conf files for
>> OpenStack, that would be usable by Deployment tools and operators.
>> Right now, Doug and I are investigating some tooling that would be
>> useful to achieve this goal.
>>
>> Doug has prototyped an Ansible role that would generate configuration
>> files by consumming 2 things:
>>
>> * Configuration schema, generated by Ben's work with Machine Readable
>> Sample Config.
>>   $ oslo-config-generator --namespace cinder --format yaml > cinder-schema.yaml
>>
>> It also needs: https://review.openstack.org/#/c/474306/ to generate
>> some extra data not included in the original version.
>>
>> * Parameters values provided in config_data directly in the playbook:
>>    config_data:
>>      DEFAULT:
>>        transport_url: rabbit://user:password@hostname
>>        verbose: true
>>
>> There are 2 options disabled by default but which would be useful for
>> production environments:
>> * Set to true to always show all configuration values: config_show_defaults
>> * Set to true to show the help text: config_show_help: true
>>
>> The Ansible module is available on github:
>> https://github.com/dhellmann/oslo-config-ansible
>>
>> To try this out, just run:
>>   $ ansible-playbook ./playbook.yml
>>
>> You can quickly see the output of cinder.conf:
>>     https://clbin.com/HmS58
>>
>>
>> What are the next steps:
>>
>> * Getting feedback from Deployment Tools and operators on the concept
>> of this module.
>>   Maybe this module could replace what is done by Kolla with
>> merge_configs and OpenStack Ansible with config_template.
>> * On the TripleO side, we would like to see if this module could
>> replace the Puppet OpenStack modules that are now mostly used for
>> generating configuration files for containers.
>>   A transition path would be having Heat to generate Ansible vars
>> files and give it to this module. We could integrate the playbook into
>> a new task in the composable services, something like
>>   "os_gen_config_tasks", a bit like we already have for upgrade tasks,
>> also driven by Ansible.
>> * Another similar option to what Doug did is to write a standalone
>> tool that would generate configuration, and for Ansible users we would
>> write a new module to use this tool.
>>   Example:
>>       Step 1. oslo-config-generator --namespace cinder --format yaml >
>> cinder-schema.yaml (note this tool already exists)
>>       Step 2. Create config_data.yaml in a specific format with
>> parameters values for what we want to configure (note this format
>> doesn't exist yet but look at what Doug did in the role, we could use
>> the same kind of schema).
>>       Step 3. oslo-gen-config -i config_data.yaml -s schema.yaml >
>> cinder.conf (note this tool doesn't exist yet)
>>
>>       For Ansible users, we would write an Ansible module that would
>> take in entry 2 files: the schema and the data. The module would just
>> run the tool provided by oslo.config.
>>       Example:
>>           - name: Generate cinder.conf
>>             oslo-gen-config: schema=cinder-schema.yaml
>>                                        data=config_data.yaml
>>

I finally caught up with this thread and got the time to get back to y'all.
Sorry.

I like the roles version more because it's flexible and easier to distribute. We
can upload it to galaxy, package it, etc. Distributing ansible modules is a bit
painful right now and you end up adding them as roles in the playbook for the
modules to be loaded.

I'm about to work on a prototype and I'll use option #1 and perhaps we can
discuss further the option #2.

Flavio

--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170626/18f89754/attachment.sig>


More information about the OpenStack-dev mailing list