Oleg, thanks. I've tried it [1], looks like it works.
- GOOD. "override_resource" resource. Like "back door" into puppet modules. - BAD. It allows just apply, not track changes. Moreover works weird, if multiple changes uploaded, applying not the latest, but initial config change. - BAD. Just limited number[1] of resources/tasks has support. BTW, my feeling that we should NOT develop this approach in the same way. I'm not an expert, but as long-term - Can we start moving all (non orchestrating) data into CMDB? yaml under git or any existing solution. - Can we track nodes state? For example, start by cron all puppet tasks with --noop option and check puppet state. Then if "out of sync" node start blinking YELLOW and user can push button, if needed. Thanks [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change [2] http://paste.openstack.org/show/481677/ On Fri, Dec 11, 2015 at 4:34 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > 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 > > -- 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