Open Stack

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