Open Stack

There are two issues conflated here maybe?

The first is a mechanism to use oslo.config to dump out example settings that could be loaded into a reference ConfigMap or etcd or something. I think there is a PS up for that.

The other is a way to get the data back into oslo.config.

etcd is one way.
using a ConfigMap to ship a file into a container to be read by oslo.config with a json/yaml/ini file driver is another.

Thanks,
Kevin
________________________________________
From: Emilien Macchi [emilien at redhat.com]
Sent: Thursday, June 08, 2017 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

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
  metadata:
    name: keystone-config
    namespace: DEFAULT
  data:
    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,

> Doug
>
>>
>> Operating on configmaps is much simpler and safer than using a different backing database for the configuration data.
>>
>> Hope the information helps.
>>
>> Ping me in #openstack-kolla if you have more questions.
>>
>> Regards
>> -steve
>>
>> -----Original Message-----
>> From: Doug Hellmann <doug at doughellmann.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
>> Date: Thursday, June 8, 2017 at 10:12 AM
>> To: openstack-dev <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla]    [helm] Configuration management with etcd / confd
>>
>>     Excerpts from Flavio Percoco's message of 2017-06-08 18:27:51 +0200:
>>     > On 08/06/17 18:23 +0200, Flavio Percoco wrote:
>>     > >On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote:
>>     > >>On 06.06.2017 18:08, Emilien Macchi wrote:
>>     > >>>Another benefit is that confd will generate a configuration file when
>>     > >>>the application will start. So if etcd is down *after* the app
>>     > >>>startup, it shouldn't break the service restart if we don't ask confd
>>     > >>>to re-generate the config. It's good for operators who were concerned
>>     > >>>about the fact the infrastructure would rely on etcd. In that case, we
>>     > >>>would only need etcd at the initial deployment (and during lifecycle
>>     > >>>actions like upgrades, etc).
>>     > >>>
>>     > >>>The downside is that in the case of containers, they would still have
>>     > >>>a configuration file within the container, and the whole goal of this
>>     > >>>feature was to externalize configuration data and stop having
>>     > >>>configuration files.
>>     > >>
>>     > >>It doesn't look a strict requirement. Those configs may (and should) be
>>     > >>bind-mounted into containers, as hostpath volumes. Or, am I missing
>>     > >>something what *does* make embedded configs a strict requirement?..
>>     > >
>>     > >mmh, one thing I liked about this effort was possibility of stop bind-mounting
>>     > >config files into the containers. I'd rather find a way to not need any
>>     > >bindmount and have the services get their configs themselves.
>>     >
>>     > Probably sent too early!
>>     >
>>     > If we're not talking about OpenStack containers running in a COE, I guess this
>>     > is fine. For k8s based deployments, I think I'd prefer having installers
>>     > creating configmaps directly and use that. The reason is that depending on files
>>     > that are in the host is not ideal for these scenarios. I hate this idea because
>>     > it makes deployments inconsistent and I don't want that.
>>     >
>>     > Flavio
>>     >
>>
>>     I'm not sure I understand how a configmap is any different from what is
>>     proposed with confd in terms of deployment-specific data being added to
>>     a container before it launches. Can you elaborate on that?
>>
>>     Doug
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev