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 <emil...@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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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