Hiera nodes is out of date after post_deployment stage when ip addresses are modified before deployment, plugins impacted

[Swann Croiset]

Steps to reproduce:

1/ .. create and configure a new cluster via Fuel UI (roles assignement, network config, plugins settings ..) BUT not "deploy changes"
2/ # fuel --env 1 deployment default
3/ .. update IP addresses for some/all nodes (sections nodes and endpoints) ..
4/ # fuel --env 1 deployment upload
5/ # fuel deploy-changes (or via Fuel UI)

Expected results:
After the OSt deployment the "hiera('nodes')" from puppet manifests returns correct information (with ip addresses configured)

Actual results:
after the OSt deployment the "hiera('nodes')" from puppet manifests returns outdated data (with ip addresses by default).

Impacts:
All Fuel plugins using hiera('nodes') will fail to configure its stuff with bad IP addresses.
Since Fuel allows to update IP addresses before deployment, (potentially) users will do it. Fuel must update the same way it does for astute.yaml the nodes.yaml with the modified data.

Environement:
Fuel 6.1 / Ubuntu (surely the same result with CentOS)
Plugins LMA collector 0.7.2

Other informations / pre diagnostic :
* OpenStack and others services (rabbitmq, haproxy ..) are correctly configured with good IPs (those updated before deployment), fortunately because the /etc/hiera/nodes.yaml is generated at post_deployment stage.
* the hiera hierarchy cannot be updated (ie move down 'nodes' after 'astute') because this will break a whole lot of stuff

Workaround:
on the plugin manifests side, instead using "hiera('nodes')", use the old school way 'parseyaml($astute_settings_yaml)'
but this workaround is not acceptable.

[Irina Povolotskaya (ipovolotskaya)]

Swann, I suppose we could move this to Fuel Plugins project in LP (or mark the bug as impacting Fuel Plugins project as well).

[Bogdan Dobrelya (bogdando)]

Added fuel pugins project. I'd say the UX impact is high or even critical here

[Aleksandr Didenko (adidenko)]

Guys, this is not library bug, nodes.yaml is being created and uploaded by nailgun. Python team should check if it's possible to make it pull correct data from deployment settings like it does for astute.yaml.

[Sheena Conant (sheena-conant)]

I would propose that we also fix this in 6.1 as an update since we have affected plugins that are available for customer use right now (ex. Zabbix).

[Patrick Petit (patrick-michel-petit)]

+1 with Sheena's request. This bug is impacting Orange who's in the process of deploying MOS 6.1 with LMA plugins.

[Evgeniy L (rustyrobot)]

Using "fuel --env 1 deployment upload" is not the best way to change ip addresses, and non-working plugin is not the worst case which user can get, since this data do not get deserialized from json into db models form, you can get ips duplication problem easily.

It will be much easier to implement and to support fully functional cli for ip management, instead of a hack ("fuel --env 1 deployment upload") which creates only problems, also I don't see that we have documented somewhere that user mustn't use until he understands consequences pretty well.

1. there won't be simple backport, we should document that user should not use "fuel --env 1 deployment upload" to change ip addresses, and it should be used for developers only

2. for 7.0 (or higher) we should create appropriate handler for ip management, I think we should decide weather it's feature or not and how difficult it will be to implement

[Ihor Kalnytskyi (ikalnytskyi)]

Yeah, I agree with Evgeniy. We are unable to work correctly in this case with any overwritten information, not only ip addresses. This is something that is incompatible with such actions by design.

If someone wants just to be able to change IP addresses it'd be better to implement a separate API call / IP addresses management. But I want to point out that would be a feature, and obvious will require much time. Hence, I'd move it to 8.0.

[Ihor Kalnytskyi (ikalnytskyi)]

Move it to 8.0 since it couldn't be fixed, we have a limitation by design and it should be done as feature.

[Simon Pasquier (simon-pasquier)]

I don't know if this should be tracked in this bug or not but to add to Evgeniy and Igor comments, the Operations guide should be fixed to remove references to the 'fuel environment upload' command [1].

[1] https://docs.mirantis.com/openstack/fuel/fuel-6.1/operations.html#adding-new-modules

[Vitaly Sedelnik (vsedelnik)]

Feature requests - Won't Fix for updates

[Bug Checker Bot (esikachev-l)]

(This check performed automatically)
Please, make sure that bug description contains the following sections filled in with the appropriate data related to the bug you are describing:

version

For more detailed information on the contents of each of the listed sections see https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Here_is_how_you_file_a_bug

[Dmitry Pyzhov (dpyzhov)]

It is a feature request and we cannot backport it to Mitaka.