Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/5e666d9a/attachment.html>