[openstack-dev] [Fuel] Configuration management for Fuel 7.0
ogelbukh at mirantis.com
Fri Dec 11 13:34:39 UTC 2015
Changing arbitrary parameters supported by respective Puppet manifests for
OpenStack services is implemented in this blueprint . It is being landed
in release 8.0.
On Thu, Dec 3, 2015 at 5:28 PM, Roman Sokolkov <rsokolkov at mirantis.com>
> little bit more research done in regards #2 usability.
> I've selected 13 real-world tasks from customer (i.e. update flag X in
> - 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
> 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.
> On Thu, Dec 3, 2015 at 11:28 AM, Oleg Gelbukh <ogelbukh at mirantis.com>
>> Thank you. This is great research.
>> Could we have a conversation to discuss this? I'm especially interested
>> in idempotency problems of the fuel-library modules and the common way to
>> provide serialised data to the deployment.
>> Best regards,
>> Oleg Gelbukh
>> Mirantis Inc
>> On Tue, Dec 1, 2015 at 6:38 PM, Roman Sokolkov <rsokolkov at mirantis.com>
>>> Hello, folks.
>>> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+
>>> will be near impossible to support. Customer always wants to change
>>> In our opinion, there are two major approaches for CM:
>>> #1 Independent CM (Puppet master, Chef, Ansible, whatever)
>>> #2 Fuel-based CM
>>> Solution for #2
>>> Fuel has all info about configuration. So we've tried to
>>> unlock "Settings"  and push "deploy" button.
>>> Major findings:
>>> * Task idem-potency. Looks like most of the tasks are idempotent.
>>> We've skipped 3 tasks on controller and were able to get NO downtime
>>> for Horizon and "nova list". BTW deeper QA required.
>>> * Standard changes. Operator can change parameters via WebUI, CLI or API.
>>> For example, i was able to deploy Sahara. Unfortunately there is not
>>> I mean some changes can lead to broken cloud...
>>> * Non-standard changes. Any other changes can be done with plugins.
>>> We can modify plugin tasks and scripts (all except UI flags). And then
>>> do "--update" + "--sync". BTW, we can change UI for particular env via
>>> by modifying "clusters/X/attributes".
>>> - This works (We have service under cron that runs tasks) 
>>> - NOT ready for production (in current state)
>>> - This requires much deeper testing
>>> I want to hear thoughts about approach above?
>>> What is the current status/plans for CM? I saw this discussion 
>>>  https://etherpad.openstack.org/p/lcm-use-cases
>>> Roman Sokolkov,
>>> Deployment Engineer,
>>> Mirantis, Inc.
>>> Skype rsokolkov,
>>> rsokolkov at mirantis.com
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Roman Sokolkov,
> Deployment Engineer,
> Mirantis, Inc.
> Skype rsokolkov,
> rsokolkov at mirantis.com
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev