Can't remove an environment if package no longer exists

Bug #1377993 reported by Steve McLellan
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Murano
Won't Fix
High
Unassigned

Bug Description

NOTE: Current behaviuor of the bug changed. An error still occurs, but the env is deleted (without deleteing the stack or calling any destroy() methods)

To reproduce:
* Upload a package
* Deploy it in an environment
* Delete the package
* Try to delete the environment

Deletion fails because the engine tries to load the package. In this circumstance I don't think it makes sense to fail; if the package is gone, we can't do any cleanup because we don't know what to do, but we should still allow the environment to be deleted i think.

Some things that could also mitigate this:
* issue a warning when deleting in-use packages
* disallow deletion for in-use packages (this is probably not what we want, especially for public ones)
* as a last ditch resort, delete the heat stack (maybe add a 'force' flag to indicate that potentially there are things that won't get cleaned up)

Related blueprint: https://blueprints.launchpad.net/murano/+spec/murano-package-tombstones

Changed in murano:
importance: Undecided → High
Revision history for this message
Stan Lagun (slagun) wrote :

The problem here is that engine just cannot load object model because it references classes that just became unknown. The same would happen if you try to redeploy environment after deletion of some packages. In this case you don't even get to executing Environment's destroy method. I don't see how this can be fixed now. Deletion of environment is just like any other action and you just cannot even start executing MuranoPL code because it cannot be loaded. Even the Environment (Core library) itself may be missing. And even if engine would have some built-in knowledge on environment deletion it will not know what to do in that case because there may be more than one Heat stack somewhere within environment and there might be some additional cleanup actions required. All your packages including core library are black boxes to engine so it cannot even know about Heat stacks.

Possible solution would be to have shadow copy of packages + package versioning so that even if you delete a package that would mean you cannot instantiate new applications but not that are environments become invalid. I'm sure even in Heat you would not be able to delete stack if it uses resource types that are no longer available (say plugin was not loaded)

Revision history for this message
Steve McLellan (sjmc7) wrote :

I agree that right now it's difficult, but i don't agree that it's unreasonable. Removing a heat resource is not a like-for-like comparison; that would be something an admin would have to do after careful consideration whereas removing packages is something anyone can and will do.

Perhaps we could change it such that you can forcibly remove knowledge of an environment (and orphan any resources it's created); any cleanup would then be the user's responsibility but at least it would be possible.

I think you're right there's not a good solution at this time.

Revision history for this message
Andrew Pashkin (apashkin) wrote :

I think there are two possible ways:
1) Teach engine to "just remove" environment.
2) Forbid to remove packages added to any environment.

Changed in murano:
status: New → Confirmed
Changed in murano:
milestone: none → liberty-1
description: updated
Revision history for this message
Kirill Zaitsev (kzaitsev) wrote :

NOTE: This bug's behaviour has been changed by this https://review.openstack.org/#/c/179533/ change. Currently the env get's deleted, but the heat-stack, created by the env remoains. Also neither of the destroy methods get called.

description: updated
Revision history for this message
Kirill Zaitsev (kzaitsev) wrote :

Folks, we now have an abandon feature, marking the bug as won't fix.

Changed in murano:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.