Dmitry, Q1. Yes.
> where do you plan to actually perform settings manipulation? It was one of the critical blockers. Most of the settings are baked inside fuel-library. Your feature [1] partially fixes this BTW. Which is good. Partially, because only limited number of tasks has defined overrides. > scheduled basis run nailgun-cm-agent Currently i see better way. nailgun-cm-agent (or whatever) should just check system status (i.e. puppet apply --noop) and report back. User will decide apply changes or not. Q2. Yes, i did. One more use case covered. Please see first table in [2]. Q4. Agree. Here is the bug [3] Q3,Q5, Q6 Good. [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change [2] https://docs.google.com/document/d/1bVVZJR73pBWB_WbfOzC-fh84pVsi20v4n3rvn38F4OI/edit (limited access) [3] https://bugs.launchpad.net/fuel/+bug/1525872 On Mon, Dec 14, 2015 at 4:39 AM, Dmitriy Novakovskiy < dnovakovs...@mirantis.com> wrote: > Roman, > > Thanks a lot for the feedback. We'll be planning improvements for [1] in > upcoming 9.0 cycle, so your input and this discussion are very helpful and > much appreciated. > > In overall, the concept for nailgun-cm-agent looks interesting, but I > think you'll face some problems with it: > - idempotency of puppet modules > - lack of exposed parameters (fuel-lib hacking) > - speed of re-runs of configuration mgmt (that we're already working on in > 8.0) > > Now, my comments and questions. > > *1) nailgun-cm-agent concept* > Q1. Do I understand correctly that the planned UX is: > - Allow user to change configuration as dictated by Fuel (btw, where do > you plan to actually perform settings manipulation? Directly in Puppet > modules/manifests?) > - On scheduled basis run nailgun-cm-agent and let it bring overall system > state to be consistent with latest changes > ? > > *2) "Advanced settings" [1] feature feedback* > Q2. Please share the details about 13 real world tasks that you used for > testing. Have you had a chance to test this same list against [1], as you > did with fuel-cm-agent approach? I need to know what from real world is > doable and what not with current state of [1] > Q3. "It allows just apply, not track changes" - that's true, 8.0 has > first MVP of this feature in place, and we don't yet have much tracking > capability (other than looking at logs in DB, when what config change yaml > was uploaded). We will be improving it in 9.0 cycle > Q4. "Moreover works weird, if multiple changes uploaded, applying not the > latest, but initial config change." - can you please share the detailed > example? I'm not sure I understood it, but so far sounds like a bug that > needs to be fixed. > Q5. "Just limited number[1] of resources/tasks has support." - this is > the limitation of what configs are shipped out of the box. When 8.0 is > released, we'll have a documented way to add support for any OpenStack > config file that Fuel tasks can reach > Q6. "Can we start moving all (non orchestrating) data into CMDB? yaml > under git or any existing solution." We're now discussing major > refactoring effort to be done in Fuel to integrate with Solar and solve > some of the long standing > > [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change > > On Fri, Dec 11, 2015 at 6:21 PM, Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> 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 >> > > -- 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
