Open Stack

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

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.  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.)

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.

I hope that helps shed a bit of light on how we’re thinking about this in the public cloud at Rackspace.

	-Thomas Duesing


On Feb 26, 2014, at 4:04 PM, Chris Behrens <cbehrens at codestud.com> wrote:


This thread is many messages deep now and I’m busy with a conference this week, but I wanted to carry over my opinion from the other “v3 API in Icehouse” thread and add a little to it.

Bumping versions is painful. v2 is going to need to live for “a long time” to create the least amount of pain. I would think that at least anyone running a decent sized Public Cloud would agree, if not anyone just running any sort of decent sized cloud. I don’t think there’s a compelling enough reason to deprecate v2 and cause havoc with what we currently have in v3. I’d like us to spend more time on the proposed “tasks” changes. And I think we need more time to figure out if we’re doing versioning in the correct way. If we’ve got it wrong, a v3 doesn’t fix the problem and we’ll just be causing more havoc with a v4.

- Chris


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4841 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/4ac42334/attachment.bin>