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
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,
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
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
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
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
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
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
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