Ansible to generate Ceph config/keys and distribute them about ceph-container

[hunter]

For some alternative thoughts, @kelseyhightower has been discussing the idea of config containers: https://twitter.com/kelseyhightower/status/615257418801393664

Example code here: https://github.com/kelseyhightower/docker-kubernetes-tls-guide/tree/master/apiserver

[Ulexus]

@leseb The gist of the Ansible solution seems to be having a centrally- (well, Anisbly-, anyway) managed configuration directory tree. I don't see a problem with that, as that's pretty much what I do, anyway (sans Ansible; seulement CoreOS), but I'm not seeing (on quickly skimming the linked document) anything we would have to do. If you want to have the script copy the configuration in from somewhere, keyed off a parameter to environment variable, that should be reasonably non-invasive.

@hunter : We have the "configuration" package ceph/config, whose intent was just this, but I'm really not sold on the idea.

The commit is still in review state for Kolla, but Kolla solution may not be ideal for Ceph. Or should I say it may be over engineered for Ceph. Since Openstack has 1,000,001 config options and a bunch of sections with shared options we are merging 6-7 configs into one final config.

Here I see a much simplier scenario:

• Minimal config in temaples/ceph.conf.j2 with the bare minimum config options needed to run.
• On the deploy host at /etc/ceph-docker/ceph.conf a file (that can be empty) for the users to add in whatever they want. New sections, new options, override options from the "minimal" config, whatever. You can also use ansible variables there.

Pass both configs through the template system and merge them on the destination host into the final location. This allows you to use the standard configini configs in a location that is under the users control rather than editting an ansible template file which would be bad practice.

---

In the end, you will have to figure out a way that works for you, I am just sharing how we do it in Kolla. Feel free to ask any additional questions!

[a-nldisr]

Will this mean that ceph-deploy will be deprecated over time and replaced by an ansible playbook?

@leseb

I stopped short of implementing this before since it seemed to be far to heavy for the project here. I believe Kevin Carter has a better way of handling this for your project. Unlike OpenStack, you only have one config and as such the method Kolla uses is not the best method for ceph-ansible in my opinion.

Since openstack-ansible is consuming ceph-ansible, this may be a union that works to everyones benefit.

Using the action plugin [1] that @cloudnull wrote would be closest to what you already have. It won't get you the ini-style config override, but it is a much more ansible-like approach to the situation.

[1] ansible/ansible#12555

[cloudnull]

Hello all, thanks @SamYaple for the mention:

The config_template plugin is an Ansible-sentric method for generating dynamic configuration files through the use of static templates which removes the need to create 1,000,001 Jinja2 variables to support the project(s). Its most of what you're looking for, according to this thread, and provides a simple means of injecting configuration options into a config file though a simple key=value data structure. The general idea has been documented here. The PR @SamYaple linked to is to implement the config_template plugin in Ansible 2.0 however If you're looking for an Anibsle 1.9.x compatible plugin we're currently carrying it here and this is how we've implemented it.

Just as an aside, the template is not tied to OpenStack in any way other than we made it to solve our use-cases however it has real world applications outside of the OpenStack work stream. If there are any questions that come from the potential use of the plugin please let me know I'd be happy to help.

[leseb]

@SamYaple thanks for the update.
@cloudnull great work thanks, I'll see how I can integrate this in ceph-ansible.
After looking at the example, it looks like it's exactly what I wanted to have :).

[cloudnull]

@leseb if you have any questions please let me know and if you have a moment to review the PR in flight for Ansible 2 ( ansible/ansible#12555 ) it would be much appreciated.

[leseb]

@cloudnull I'll likely have some questions as soon as I give it a try. Thanks for your support :).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.