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 <ogelb...@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 <rsokol...@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, >> rsokol...@mirantis.com >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev