Open Stack

Hi, Roman

So here is how we think we are going to tackle this. The whole idea is to
make Fuel architecture much more flexible. We are actively working on this
and are going to present draft of initial documents pretty shortly before
the end of the year.


* *Short (very-very short) summary of our plan*

*** Nailgun will be split into pieces*

*** *Managers split-off*
Business logic things such as network allocation, volume allocation and so
on are going to become services with their own APIs

**** Serializers externalization and pluggability*

Current serializers are going to become separate entities that will be
pluggable and easily extendable. These serializers will be able to consume
data from any service you register in Nailgun as a data source. These data
sources could be:

1) Nailgun network/volume/openstack_cluster managers
2) any 3rd party service with an API:
  a) LDAP
  b) Inventory
  c) external puppet master
  d) etc.

*** There is going to be a configuration storage*

All the stuff created by serializers is going to be stored in a database in
versioned and hierarchical format.
This storage will be a source for deployment tasks execution.

*** Difference in configuration is going to be handled by new components*

Right now we have some PoC code to make it happen and once it reaches
working stage, we will upload it to upstream and continue working on it in
open format. It is going to consume the difference between cluster
configuration and orchestrate execution of particular deployment tasks from
Fuel Library or any other 'runnable' resource wrapped into its format, e.g.
container, ansible playbook, whatever.

** How it is all related to you problem*

In this case you should be able to proof-test this approach - you could
take any simple DB and make current serializers store data into this DB.
This will allow you to fetch additional data from other sources and write
also to this config DB. E.g. if you want to fetch some data from puppet
master - do the following:
1) send a request to puppet master to compile the catalogue for a
particular node
2) parse this catalogue and extract required things into config DB
3) run deployment with new values from config db

** Existing feature tackling this issue*

BTW, there is already a feature which partially addresses your demands:
https://blueprints.launchpad.net/fuel/+spec/openstack-config-change

** Idempotency fixes*

Well, if you find any problems - please file bugs. There are some execs in
puppet code which make tasks not 100% idempotent, but these execs are
actually harmless. If you find any other issues with idempotency - please,
file bugs for them.

** Issues like '**amqp_durable_queues**' redefinition*

These issues are going to be tackled by strict responsibilities
distribution between 'serializers' part and deployment tasks part.

E.g. there should be no more than 1 task doing one thing. 'amqp_durable_queues'
should be configured exactly with one task, not with 2 tasks.

To achieve this the plugin you mentioned should only change the value of '
amqp_durable_queues' in the config DB, while the regular task that will be
called will be the one you have in the core of Fuel Library.

** Issues with deployment time*

We are working hard on introducing improved orchestration in experimental
mode in 8.0 - please check out
https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute

Hope, my answer was not too long. Feel free to ask questions.

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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151203/95e2a4f7/attachment.html>