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....@gmail.com> wrote: > Hi, Roman. > > On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov <rsokol...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev