Plugin doesn't have an access to its own data in pre-deployment tasks on master node.

[Stanislaw Bogatkin]

In our current plugins implementation tasks decoupled to several entities - pre-deployment, deployment, post-deployment. Also there several nodes when plugin can be ran, like master node and env nodes. Plugin have an access to cluster data (and to plugin own data) not in all cases. Here the flow:

User press 'Deploy Changes';

1. plugin pre-deployment for master node starts
2. plugin pre-deployment for slave node starts
3. plugin deployment for slave node starts
4. plugin post-deployment for slave node starts

With current approach plugin can't retrieve ANY data about environment on 1 step (but data already exists in DB), but there are plugins which wanted such access - and it's absolutely normal to have it.

So we need to provide for plugin on pre-deployment step on master node data about environment, like CLUSTER_ID, common cluster attributes and plugin attributes from environment_config.yaml file.

[Evgeniy L (rustyrobot)]

I think for plugin's Master tasks we should put the data which are generated by `get_common_attrs` [1] method.

[1] https://github.com/openstack/fuel-web/blob/26c78e1c2913b8ca194126ca38161ff9593daef4/nailgun/nailgun/orchestrator/deployment_serializers.py#L108

[Ihor Kalnytskyi (ikalnytskyi)]

The question is how we should send this information? Should we send it in separate field? if so, i don't like it - it will be duplicated to each node, which is wrong.

Perhaps as quick fix, Astute can upload astute.yaml of first node to master. The common information will be accessible there.

But the good solution should be done, perhaps, by introducing an implicit master node from nailgun which will have only a limtted set of attributes.

[Vladimir Sharshov (vsharshov)]

Simple solution to add any node file to master node will not work because it will fail in case of 2 parallel deployments.

We need more better and document solution.

[Stanislaw Bogatkin (sbogatkin)]

Could we do it the way we do it for keys - create a directory with cluster id number and save data to it?

[Vladimir Sharshov (vsharshov)]

My suggestion:

   On Astute side: add special hook which should save master node data into special place;
   On doc side: add doc about path on master node for plugin developers.

As i remember, now everyone can use {CLUSTER_ID} in task description in case of 8.0, so we do not have problem to setup path where plugin should find it own info.

But we still have question what info should be placed on such master node Astute YAML. We can add master node with common info into deployment info array. In this case we can control content of it in one place. In this case we also should remove master node from upload/symlink hooks.

[Stanislaw Bogatkin (sbogatkin)]

Currently, plugin can't define for which cluster it's run, cause serializer for this wasn't merged yet, if I remember right. So, this task also should be done.
Absolutely agree about docs.

As to data in this yaml - plugin data and common cluster attributes seems okay for me.

[Evgeniy L (rustyrobot)]

Lets create a task upload_file in pre deployment, in the same way we do tasks for repos creation, and the content of the file will be [0] common attributes. Master tasks should be run with special environment variable which is set to the path where this yaml is placed.

[0] https://github.com/openstack/fuel-web/blob/26c78e1c2913b8ca194126ca38161ff9593daef4/nailgun/nailgun/orchestrator/deployment_serializers.py#L108

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/270136

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/271242

[Ihor Kalnytskyi (ikalnytskyi)]

The issue itself isn't a regression. We never support such functional before. Taking into account that it's not a bug, but a useful enhancement and HCF is really close, mark this bug as Won't Fixed for 8.0.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexander Kislitsky (<email address hidden>) on branch: master
Review: https://review.openstack.org/271242
Reason: This change is not actual after tasks refactoring

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexander Kislitsky (<email address hidden>) on branch: master
Review: https://review.openstack.org/270136
Reason: This change is not actual after tasks refactoring

[Alexander Kislitsky (akislitsky)]

We already have deployment info after tasks refactoring.
Reassigning to @Bulat.

[Dmitry Pyzhov (dpyzhov)]

We passed SCF for 9.0. Moving the medium priority bug to 10.0 release.