[openstack-dev] [Heat] Stack Abandon/Adopt in Juno

Zane Bitter zbitter at redhat.com
Fri Sep 26 19:44:18 UTC 2014


At the time of the Icehouse release, we realised that the just-merged 
stack abandon/adopt features were still in a very flaky state. A bunch 
of bugs were opened and in the release notes we called this out as a 
'preview' feature, not fully supported.

Fast-forward 6 months and we still have a bunch of open bugs (although 
others have been fixed, including at least one in Juno):

https://bugs.launchpad.net/heat/+bug/1300336
https://bugs.launchpad.net/heat/+bug/1301314
https://bugs.launchpad.net/heat/+bug/1301323
https://bugs.launchpad.net/heat/+bug/1350908
https://bugs.launchpad.net/heat/+bug/1353670

The first bug has patches with unacknowledged -1 comments. The others 
don't appear to have been started. Two of these are in the -rc1 bug 
list, and given that there appears to be a negligible chance of them 
actually being fixed we need to decide what to do about them.

Particular areas of concern:

* bug 1353670

Basically we all agree that we need to change the semantics of the 
abandon call to prevent it deleting the critical data _before_ returning 
it to the user.

* bug 1301323

The writeup on this suggests that it will present a potential security 
hole once bug 1300734 is fixed - which it has been, but this one is 
still not.


I don't know that there are any good solutions here. Abandon is a really 
handy thing to have around to get you out of trouble (although we hope 
that with Juno people won't get into trouble quite as often). But I'm 
not sure that we can go another release claiming this as a 'preview', 
especially with potential security issues involved. Given that 
approximately nobody reads the release notes it's a bit of a cop-out and 
in retrospect was probably a mistake last time.

What do folks think about adding a config option for this feature (or 
even separate ones for abandon & adopt?) and disabling it by default?

Maybe in future we should consider doing this for all new API changes, 
so they always get the time they need to bed in regardless of when in 
the release cycle they land.

cheers,
Zane.



More information about the OpenStack-dev mailing list