Open Stack

On 8 June 2017 at 09:50, Michał Jastrzębski <inc007 at gmail.com> wrote:
> On 8 June 2017 at 09:27, Flavio Percoco <flavio at redhat.com> wrote:
>> 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.
>
> Well, I disagree. If we're doing this we're essentially getting rid of
> "files" at all. It might actually be easier to handle from COE than
> configmap, as configmap has to be generated and when you get to host
> specific things it's quite a pain to handle. I, for one, would happily
> use cantral DB for config options if we define schema correctly.
>
> That being said defining schema correctly is quite a challenge. Few
> hard cases I see right now can be found in single use case - PCI
> Passthrough
>
> 1. I have multiple PCI devices in host, I need to specify list of them
> 2. PCI buses differes host to host, I need to specify groups of hosts
> that will share same bus configuration and reflect that in service
> config
>
> Maybe we should gather few of hard use cases like that and make sure
> we can address them in our config schema?

Speaking of hard use cases: here's another - config rolling upgrade +
config rollback. If we have single option in etcd, when service
restarts it automatically gets new config which creates funny edge
cases when you want to do rolling upgrade of config and some other
node fails->service restarts->config gets updated "accidentally".

>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __________________________________________________________________________
>> 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
>>