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 <rsokol...@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 <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 > >
__________________________________________________________________________ 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
