Open Stack

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 <
dnovakovskiy at 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 <rsokolkov at 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 <ogelbukh at 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 <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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>
>


-- 
Roman Sokolkov,
Deployment Engineer,
Mirantis, Inc.
Skype rsokolkov,
rsokolkov at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151214/ed2a9dd8/attachment.html>