openstack team mailing list archive

[Michael Basnight <mbasnight@xxxxxxxxx>]

On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:
>
> On Jul 12, 2012, at 11:48 AM, Christopher B Ferris wrote:
>
>> This level of response is unnecessary.
>>
>> That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact.
>
> Agreed, I'm a developer, so I'm clearly biased towards what is easier for developers. It will be a significant effort to have to maintain the nova-volume code, so I want to be sure it is necessary. End users really shouldn't care about this, so the other community members who are impacted are operators.
>
> I really would like more feedback on how painful it will be for operators if we force them to migrate. We have one clear response from Chuck, which is very helpful. Is there anyone else out there running nova-volume that would prefer to keep it when they move to folsom?

Us reddwarfers are running a grunch of nova volumes in multiple DCs.
While the developer in me says lets go w/ option 1, the
release/operator in me says lets wait to do this on a formal release
(#2?). It seems like we are too far gone in the Folsom release to do
this w/o people having to scramble. Everyone will have to eventually
migrate from old to new, and while i understand that there will be a
clear path to do this, and its going to be painful for some companies.
If we rip things out during Grizzly, it will at least give companies
that are not rolling on trunk the ability to decide when to migrate.
If you do it in Folsom, some companies who are depending on (or
wanting) landed features, but may not be able to do this migration,
could suffer. At least now deferring to El Oso will give companies
time to brace themselves, and successfully migrate to Folsom w/o any
major issues. In general it makes sense to do sweeping changes between
major releases, communicated at the beginning of a release cycle
rather than in the middle, to give operators/companies a decision to
upgrade if they want the features vs stay on old if they dont want to
migrate. At the end of the day, openstack depends on operators to
function. Id rather piss of us developers than piss off the people
that run the infrastructure we create!

That being said, im not worried about the migration, given that its
just a datastore/service/package/installation based migration. We will
likely roll to cinder much sooner than the Grizzly release, assuming
everything is stable (which im sure it will be). :)