Open Stack

Hi, Roman.

On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov <rsokolkov at mirantis.com>
wrote:

> I've selected 13 real-world tasks from customer (i.e. update flag X in
> nova.conf):
> - 6/13 require fuel-library patching (or is #2 unusable)
> - 3/13 are OK and can be done with #2
> - 4/13 can be done with some limitations.
>
> If needed i'll provide details.
>
> Rough statistics is that *only ~20-25% of use cases can be done with #2*.
>
> Let me give a very popular use case that will fail with #2. Assume we'r
> executing whole task graph every two hours.
> We want to change nova.conf "DEFAULT/amqp_durable_queues" from False to
> True.
>
> There is no parameter in hiera for "amqp_durable_queues". We have two
> solutions here (both are bad):
> 1) Redefine "DEFAULT/amqp_durable_queues" = True in plugin task. What will
> happen on the node. amqp_durable_queues will continue changing value
> between True and False on every execution. We shouldn't do it this way.
> 2) Patch fuel-library. Value for amqp_durable_queues should be taken from
> hiera. This is also one way ticket.
>

You are describing one of use cases we want to cover in future with Config
Service. If we store all configuration variables consumed by all deployment
tasks in the service, one will be able to change (override) the value in
the same service and let deployment tasks apply config changes on nodes.

This would require support from the deployment side (source of all config
values will become a service, not static file) and from Nailgun (all data
should be stored in the service). In the future this approach will allow us
to clarify which value goes where and to define new values and override old
ones in a clearly manageable fashion.

Config Service would also allow us to use data defined outside of Nailgun
to feed values into deployment tasks, such as external CM services (e.g.
Puppet Master).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151203/36befe4d/attachment.html>