Open Stack

Hi there,

one small step into this direction. I've checked how idempotent
controller's tasks. As result bugs below were reported:

https://bugs.launchpad.net/fuel/+bug/1524759 NEW
https://bugs.launchpad.net/fuel/+bug/1524747 NEW
https://bugs.launchpad.net/fuel/+bug/1524731 NEW
https://bugs.launchpad.net/fuel/+bug/1524727 NEW
https://bugs.launchpad.net/fuel/+bug/1524724 NEW
https://bugs.launchpad.net/fuel/+bug/1524719 NEW
https://bugs.launchpad.net/fuel/+bug/1524713 NEW
https://bugs.launchpad.net/fuel/+bug/1524687 NEW
https://bugs.launchpad.net/fuel/+bug/1524630 NEW
https://bugs.launchpad.net/fuel/+bug/1524327 CONFIRMED
https://bugs.launchpad.net/fuel/+bug/1522857 IN PROGRESS

If it's interesting i can go thru other roles and tasks? Please let me know.

Thanks



On Thu, Dec 3, 2015 at 10:33 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:

> 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).
>
> __________________________________________________________________________
> 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
>
>


-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokolkov at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151210/fe0bf23f/attachment.html>