On Thu, Jul 12, 2012 at 2:38 PM, Vishvananda Ishaya <vishvana...@gmail.com> 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). :) _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp