Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-14 Thread Roman Sokolkov
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

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-11 Thread Oleg Gelbukh
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,

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-11 Thread Roman Sokolkov
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

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-10 Thread Roman Sokolkov
Hi there, one small step into this direction. I've checked how idempotent controller's tasks. As result bugs below were reported: https://bugs.launchpad.net/fuel/+bug/1524759 NEW https://bugs.launchpad.net/fuel/+bug/1524747 NEW https://bugs.launchpad.net/fuel/+bug/1524731 NEW

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-03 Thread Oleg Gelbukh
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

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-03 Thread Roman Sokolkov
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

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-03 Thread Yuriy Taraday
Hi, Roman. On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov wrote: > 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

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-03 Thread Vladimir Kuklin
Hi, Roman So here is how we think we are going to tackle this. The whole idea is to make Fuel architecture much more flexible. We are actively working on this and are going to present draft of initial documents pretty shortly before the end of the year. * *Short (very-very short) summary of our

[openstack-dev] [Fuel] Configuration management for Fuel 7.0

2015-12-01 Thread Roman Sokolkov
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