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 <cbehr...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
