I missed [tripleo] tag. On Thu, Jun 15, 2017 at 12:09 PM, Emilien Macchi <[email protected]> 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 > > > Please bring feedback and thoughts, it's really important to know what > folks from Installers think about this idea; again the ultimate goal > is to provide a reference tool to generate configuration in OpenStack, > in a way that scales and is friendly for our operators. > > Thanks, > > [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118176.html > -- > Emilien Macchi
-- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
