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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
