[openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd
doug at doughellmann.com
Thu Jun 8 20:31:12 UTC 2017
Excerpts from Emilien Macchi's message of 2017-06-08 22:20:34 +0200:
> On Thu, Jun 8, 2017 at 8:49 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> > Excerpts from Steven Dake (stdake)'s message of 2017-06-08 17:51:48 +0000:
> >> Doug,
> >> In short, a configmap takes a bunch of config files, bundles them in a kubernetes object called a configmap, and then ships them to etcd. When a pod is launched, the pod mounts the configmaps using tmpfs and the raw config files are available for use by the openstack services.
> > That sounds like what confd does. Something puts data into one of
> > several possible databases. confd takes it out and writes it to
> > file(s) when the container starts. The app in the container reads
> > the file(s).
> > It sounds like configmaps would work well, too, it just doesn't
> > sound like a fundamentally different solution.
> Sorry for my lack of knowledge in ConfigMap but I'm trying to see how
> we could bring pieces together.
> Doug and I are currently investigating how oslo.config can be useful
> to generate the parameters loaded by the application at startup,
> without having to manage config with Puppet or Ansible.
> If I understand correctly (and if not, please correct me, and maybe
> propose something), we could use oslo.config to generate a portion of
> ConfigMap (that can be imported in another ConfigMap iiuc) where we
> would have parameters for one app.
> Example with Keystone:
> apiVersion: v1
> kind: ConfigMap
> name: keystone-config
> namespace: DEFAULT
> debug: true
> rpc_backend: rabbit
> ... (parameters generated by oslo.config, and data fed by installers)
> So iiuc we would give this file to k8s when deploying pods. Parameters
> values would be automatically pushed into etcd, and used when
> generating the configuration. Am I correct? (I need to understand if
> we need to manually manage etcd key/values).
> In that case, what deployments tools (like Kolla, TripleO, etc) would
> expect from OpenStack to provide (tooling in oslo.config to generate
> ConfigMap? etc.
> Thanks for your help,
Based on  I think the idea is to write the entire config file
for the service outside of the container, upload it to the configmap,
then configure the pod to create a volume and write the configmap
contents to the volume before launching the container. It's sort of like
nova's file-injection feature.
The approach seems appealing, although I don't fully understand the
issues others have raised with adding volumes to containers.
More information about the OpenStack-dev