Keys generated by Fuel Master are not deleted when environment is deleted.

[Javier Diaz Jr]

Mirantis OpenStack 9.0 tested only.

Detailed bug description:

When an environment is deployed, keys are generated and stored in the location /var/lib/fuel/keys/<env_id>/ at the Fuel master node. When the environment is deleted these keys are not deleted. As a consequence, when the environment is deployed again with different DNS hostname, then deployment will fail.

Steps to reproduce:

- Deploy an environment
- Check that keys are present in Fuel master node at /var/lib/fuel/keys/<env_id>/
- Delete the environment
- Check that keys are still present in Fuel master node at /var/lib/fuel/keys/<env_id>/
- Reset nailgun database (so that next environment will get the same environment ID)
- Create an environment and update the DNS hostname to a different name in the settings tab
- Deploy an environment and it will fail.

Expected results:

When environment is deleted the keys should be deleted as well.

Actual result:

Keys remain.

Reproducibility:

100%

Workaround:

Remove keys manually.

Description of the environment:

MOS 9.0
CentOS 7 (Fuel Master)

Impact:

Depending on use case customer may be affected if the scenario described in the reproduction steps is replicated. Not probable (I think), nonetheless, its a problem.

[Denis Meltsaykin (dmeltsaykin)]

It looks related to https://bugs.launchpad.net/fuel/+bug/1507361

[Alexey Stupnikov (astupnikov)]

This issue is similar to the one described in bug #1507361, which reports the same problem during reset process. We can solve this issue in the same fashion: cast additional RemoveClusterKeys call.

[OpenStack Infra (hudson-openstack)]

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

[Vladimir Kozhukalov (kozhukalov)]

"reset database" does not look like a valid procedure in the Fuel workflow. If one does this manually, then one could remove keys manually as well. I don't think we need to delete keys when we delete an environment (the same for logs), but anyway the best way to customize the graph, but not by hardcoding yet another subtask in nailgun.

[Alexey Stupnikov (astupnikov)]

@vkozhukalov, If you`ll google for 'nailgun manage.py dropdb', some official docs will come up in search results. If there is official documentation, then IMO we should support this kind of workflows.

Another point about graph's customization is totally right, but its realization will make this patch non-backportable and shouldn't be used given that we used the same unconditional call after environment's reset:
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/task/manager.py#L920

[Dmitry Pyzhov (dpyzhov)]

Database reset is not recommended procedure in any production environment. Please share links to documentation that claims otherwise and we'll fix docs.

As a workaround for your particular case please delete keys manually.

[Alexey Stupnikov (astupnikov)]

@dpyzhov, sorry, but I haven't seen 'recommended procedure' and 'not recommended procedure' phrases anywhere in Mirantis documentation. You can check links below, no warnings about possible problems there:

[1] https://answers.launchpad.net/fuel/+question/257794

[2] http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/file-ref/openstack-yaml.html

Besides, even if it is not recommended unofficially, why it is not legitimate action that we shouldn't support?

[Javier Diaz Jr (javierdiazcharles)]

@astupnikov

The bug is of high importance to the customer. There is a known workaround to this issue (i.e. manunal delete of keys), however, customer has marked case as severity 2 (high) and considering they deploy environments very frequently it would ease their process in doing so if we address this.

[Alexey Stupnikov (astupnikov)]

@dpyzhov, it is up to core developers to decide whether to consider this problem as a bug or not to do so for master branch. On the other hand, our team is responsible for stable branches and I discussed this issue with maintenance team before writing a patch. I will re-open this bug for Newton, Mitaka and Liberty releases.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/413597

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/413621

[Dmitry Pyzhov (dpyzhov)]

@Alexey, sorry, but this is a community project and your team is not in charge for stable/newton and stable/mitaka branches. According to PTL and core team decision this bug is invalid and it is an expected behaviour. Please use the workaround.

[Alexey Stupnikov (astupnikov)]

There is no point to fix this only for stable/8.0 as this bug was reported for stable/mitaka. Closing as invalid.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexey Stupnikov (<email address hidden>) on branch: stable/mitaka
Review: https://review.openstack.org/413597
Reason: This patch doesn't fit with Fuel team plans and is not going to be merged.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexey Stupnikov (<email address hidden>) on branch: master
Review: https://review.openstack.org/408516
Reason: This patch doesn't fit with Fuel team plans and is not going to be merged.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alexey Stupnikov (<email address hidden>) on branch: stable/newton
Review: https://review.openstack.org/413621
Reason: This patch doesn't fit with Fuel team plans and is not going to be merged.

[Javier Diaz Jr (javierdiazcharles)]

Changed to won't fix.

Won't fix: Doesn't fit with the project plans, sorry.

Reason for abandonment: This patch doesn't fit with Fuel team plans and is not going to be merged.