Open Stack

On Fri, Sep 26, 2014 at 03:44:18PM -0400, Zane Bitter wrote:
> 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.

I agree, I think it's really unfortunate the way this has played out.

If it weren't a feature which I think some folks are actually using, I'd be
tempted to say lets revert the whole thing, given the nature of the
long-standing issues, and that it's, umm, not exactly been actively
maintained by the original author.. :(

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

Obviously the risk here is that the disabled bugginess then persists
forever, so if we go down this route, I'd like to get some assurances from
those involved with or interested in this feature that the problems will
get worked out during Kilo, with a view to re-enabling in future.

Also, this is a terrible experience for users from an API versionining
perspective - we probably need to move towards an discoverable optional
extension model, or micro-versioning, so folks have some chance of figuring
out what functionality exists in a given heat endpoint.

Until recently I was of the opinion that incrementally adding things to the
API was OK, but  this is a prime example of why it's actually not IMO.

Steve