Open Stack

I think I missed the emphasis on the efforts towards superseding and/or making the call obsolete in my previous email (I was aiming to communicate far more than a the few lines managed to convey). I honestly think that if we are sticking with V2 because of the fact that Nova is such a large surface area, the only option is to treat each extension as it’s (almost) own isolated API in the context of deprecation, obsolescence, etc. I think the issue here is that we may be looking at the version of the API like something fixed in stone. Clearly, with the scope and surface area of Nova (this point has been made clear), there is no possible way we can handle a whole-sale change.

As a deployer, and supporter of a number of OpenStack based clouds, as long as the API is stable (yes, I’ll give it a full year from when it is determined a change is needed), I don’t see my customers complaining excessively; maybe we make it a 4 cycle deprecation? It is silly to say “because we called it X we can’t ever take anything away”. I am all for not breaking the contract, but define the contract beyond “the spec”. This holds true especially when it comes down to continued growth and possibly moving the data from one place to somewhere better / more suited. Perhaps part of the real issue is the whole extension model. A well documented, interoperable (across deployments) API doesn’t have huge swaths of functionality that is optional (or more to the point what is OpenStack Compute’s API?). If you are adding a core-feature it should it be an “Extension”? 

Lets add one more step in, ask deployments if they are using the “extensions”? Make it part of the summit / development cycle. Get real information (send surveys?) and get to know the community running the software. That in itself will help to direct if an extension is used. I think the crux is that we do not have a clear (and have no way of getting the information) understanding of what is being used and what isn’t. Perhaps the best thing we can do is make this an exercise on understanding what people are using and how we can quantify that information before we worry about “how do we remove functionality”.

Complete removal of functionality is probably going to be rare. It is far more likely that locations will shift and / or things will be rolled into more logical areas.  At the speed that we are moving (not slow, but not as fast as other things), it should be totally possible to support a 2+ cycle deprecation if something is being moved / shuffled / absorbed. But more importantly, knowing use is far more important that knowing how to remove, the former will direct the latter.


So I propose changing the topic of this thread slightly: In a V2 only world, how do we know if something is used? How do we understand how it is used and when? Lets answer that instead.


—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m at metacloud.com


On March 4, 2014 at 02:09:51, Christopher Yeoh (cbkyeoh at gmail.com) wrote:

On Mon, 3 Mar 2014 21:31:23 -0800
Morgan Fainberg <m at metacloud.com> wrote:
>  
> I think that in a V2 only world a 2 cycle deprecation model would be
> sufficient for any extension. I don’t foresee any complaints on that
> front, especially if there is work to supersede or obsolete the need
> for the extension.

Given the context of feedback saying we're not able to deprecate
the V2 API as-it-is for a very long time I don't see how a 2 cycle
deprecation model for an extension is sufficient. Perhaps it comes down
to how do we really know its unused? If it hasn't ever worked (we had
one of those!) or accidentally hadn't worked for a couple of cycles and
no one noticed then perhaps deprecating it then is ok. But otherwise
whilst we can get input from public cloud providers fairly easily
there's going to be a lot of small private deployments as well with
custom bits of API using code which we won't hear from. And we'll be
forcing them off the API which people say is exactly what we don't want
to do.

Deprecating functionality and still calling it V2 is I think nearly
always a bad thing. Because it is very different from what people
consider to be major version API stability - eg you may get new
features, but old ones stay.

Its for similar reasons I'm pretty hesitant about using microversioning
for backwards incompatible changes in addition to backwards compatible
ones. Because we end up with a concept of major version stability which
is quite different from what people expect. I don't think we should be
seeing versioning as a magic bullet to get out of API mistakes
(except perhaps under really exceptional circumstances) we've made
because it really just shifts the pain to the users. Do it enough and
people lose an understanding of what it means to have version X.Y
of an API available versus X.(Y+n) and whether they can expect the
software to still work.




>  
> Cheers,
> Morgan 
> —
> Morgan Fainberg
> Principal Software Engineer
> Core Developer, Keystone
> m at metacloud.com
>  
>  
> On March 3, 2014 at 21:29:43, Joe Gordon (joe.gordon0 at gmail.com)
> wrote:
>  
> Hi All,  
>  
> here's a case worth exploring in a v2 only world ... what about some  
> extension we really think is dead and should go away? can we ever  
> remove it? In the past we have said backwards compatibility means no  
> we cannot remove any extensions, if we adopt the v2 only notion of  
> backwards compatibility is this still true?  
>  
> best,  
> Joe  
>  
> _______________________________________________  
> OpenStack-dev mailing list  
> OpenStack-dev at lists.openstack.org  
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/dc1a6d25/attachment.html>