Open Stack

----- Original Message -----
> Howdy!  I’m a Product Manager for Cloud Servers at Rackspace, and wanted to
> add a bit to what Behrens is saying.

I'm a Product Manager covering OpenStack over at Red Hat - and largely concentrating on Nova no less, so I'll jump in and provide the view from my side though on face value I think it's *mostly* in line with your comments.

> At Rackspace, we’ve experienced something like this (if you squint and look
> at it sideways) in the operation of our non-OpenStack cloud (“first gen
> Cloud Servers”) alongside our OpenStack cloud (“next gen Cloud Servers”).
> We introduced first gen Cloud Servers in 2008 and next gen in August of
> 2012, and we have yet to migrate off of our first gen platform.  When all is
> said and done, first gen and next gen Cloud Servers will probably coexist
> for three years.  And really, the timeline on this migration is driven by
> boring finance-y reasons like datacenter efficiency and operational costs -
> if we didn’t have that stuff to push us along, who knows how long first gen
> would be around.
>
> Another thing we learned from our next gen launch is that most customers
> won’t self-migrate to a new and improved platform unless they see a whole
> bunch of real value.  Migrations are hard.  That is to say, Nova’s v3 API
> will have to provide tangible benefits to our customers before we implement
> it, much less migrate away from v2.  

This really comes back to Monty's point, if the migration between v2 and v3 is seamless to deployers, operators and users of the language bindings, command line clients, etc. then the API no longer has to "sell" itself in that fashion which is an unenviable and arguably impossible task. Anything that introduces friction to the migration process however increases the chances that people won't move to the new version for a long time, whether it's marked deprecated or not.

So if it can indeed be seamless it isn't as much of an issue. My concern though is I don't think that's something we've necessarily achieved in previous API bumps in OpenStack projects (as evidenced in turn by the fact that even some of the other OpenStack projects haven't picked them up) so we need to carefully consider what can be done to improve the migration experience as we look towards doing another such bump.

> Full transparency: in talking with our customers, we’re not hearing them express problems that v3 solves.  (That’s
> not to say I don’t totally see where the v3 project is coming from and
> appreciate all the hard work that’s gone into it - I really do.)

I have in fact had at least a subset of customers express interest specifically in the tasks functionality, and more accurately some of the future functionality it would enable in terms of interacting with tasks. That said I am still under the perhaps misguided impression that implementing tasks on v2 would not be *completely* impossible - smarter people than me have debated and will no doubt continue to debate how practical/reasonable that would really be and the relevant compromises to the design though. Either way, just wanting to provide a data point to indicate that it is something at least a subset of customers are aware of and following.

> Additionally, and this is has been touched on throughout this thread, we’ve
> got a lot of touch points internally and upstream before we would consider
> deprecating the v2 API: knowledge center articles, API documentation, SDKs
> (we officially contribute to/maintain at least seven), CLI clients, two
> mobile apps, mycloud.rackspace.com, my.rackspace.com, Heat, devops tools
> like knife-rackspace and vagrant-rackspace, our entire support floor,
> operations teams, etc.

This is a crucial point. An API is implicitly valued as much for the ecosystem around it as it is anything directly in the API itself. So from my point of view it's as important to ask not just if we do v3 but if we do what's an appropriate length of time to allow work for documentation, bindings, and clients to catch up without removing v2 and can the Nova team accept the maintenance required in the interim.

My feeling both with my product hat and my upstream documentation contributor hat on knowing some of the issues we've had there in the past is that one release cycle of deprecation for v2 would not be enough notice for this kind of change, particularly if it's also a cycle where v3 is still being pretty actively worked on and a moving target for the rest of the ecosystem (which it looks like will be the case for Juno, if we continue in the direction of doing v3).

Thanks,

Steve