[openstack-dev] [Fuel] Configuration management for Fuel 7.0

Roman Sokolkov rsokolkov at mirantis.com
Fri Dec 11 17:21:04 UTC 2015


Oleg,

thanks. I've tried it [1], looks like it works.

- GOOD. "override_resource" resource. Like "back door" into puppet modules.
- BAD. It allows just apply, not track changes. Moreover works weird,
if multiple changes uploaded, applying not the latest, but initial
config change.
- BAD. Just limited number[1] of resources/tasks has support.

BTW, my feeling that we should NOT develop this approach in the same way.

I'm not an expert, but as long-term
- Can we  start moving all (non orchestrating) data into CMDB? yaml under
git
or any existing solution.
- Can we track nodes state? For example, start by cron all puppet tasks
with --noop option
and check puppet state. Then if "out of sync" node start blinking YELLOW
and user
can push button, if needed.

Thanks

[1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change
[2] http://paste.openstack.org/show/481677/

On Fri, Dec 11, 2015 at 4:34 PM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:

> Roman,
>
> Changing arbitrary parameters supported by respective Puppet manifests for
> OpenStack services is implemented in this blueprint [1]. It is being landed
> in release 8.0.
>
> [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Thu, Dec 3, 2015 at 5:28 PM, Roman Sokolkov <rsokolkov at mirantis.com>
> wrote:
>
>> Folks,
>>
>> little bit more research done in regards #2 usability.
>>
>> 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.
>>
>> Thanks
>>
>>
>>
>>
>>
>> On Thu, Dec 3, 2015 at 11:28 AM, Oleg Gelbukh <ogelbukh at mirantis.com>
>> wrote:
>>
>>> Roman,
>>>
>>> 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>
>>> wrote:
>>>
>>>> Hello, folks.
>>>>
>>>> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+
>>>> nodes
>>>> will be near impossible to support. Customer always wants to change
>>>> something.
>>>>
>>>> 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" [0] 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
>>>> foolproof.
>>>> 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
>>>> just
>>>> do "--update" + "--sync". BTW, we can change UI for particular env via
>>>> API
>>>> by modifying "clusters/X/attributes".
>>>>
>>>> Conclusion
>>>> ----------
>>>>
>>>> - This works (We have service under cron that runs tasks) [1]
>>>> - 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 [2]
>>>>
>>>> References
>>>> ----------
>>>>
>>>> [0]
>>>> https://github.com/rsokolkov/fuel-web/commit/366daaa2eb874c8e54c2d39be475223937cd317d
>>>> [1]
>>>> https://docs.google.com/presentation/d/12kkh1hu4ZrY9S6XXsY_HWaesFwESfxbl5czUwde8isM/edit#slide=id.p
>>>> [2] 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)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20151211/96268888/attachment-0001.html>


More information about the OpenStack-dev mailing list