Vish, How would the Nova migration from Essex to Folsom take place ? I'm wondering how we can validate Folsom without risking an existing Essex installation via some sort of clone/migrate operation.
What is your assessment of the risk that Cinder is less stable than Nova volume ? Option 1 would give no option if there are issues, we would have either to stay on Essex entirely or wait until Folsom has the issues resolved. However, option 1 would be much cleaner code wise. Tim > -----Original Message----- > From: openstack-bounces+tim.bell=cern...@lists.launchpad.net > [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf > Of Vishvananda Ishaya > Sent: 11 July 2012 17:27 > To: Openstack (openstack@lists.launchpad.net) > (openstack@lists.launchpad.net) > Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom > > Hello Everyone, > > Now that the PPB has decided to promote Cinder to core for the Folsom > release, we need to decide what happens to the existing Nova Volume code. > As far as I can see it there are two basic strategies. I'm going to give an > overview of each here: > > Option 1 -- Remove Nova Volume > ============================== > > Process > ------- > * Remove all nova-volume code from the nova project > * Leave the existing nova-volume database upgrades and tables in > place for Folsom to allow for migration > * Provide a simple script in cinder to copy data from the nova > database to the cinder database (The schema for the tables in > cinder are equivalent to the current nova tables) > * Work with package maintainers to provide a package based upgrade > from nova-volume packages to cinder packages > * Remove the db tables immediately after Folsom > > Disadvantages > ------------- > * Forces deployments to go through the process of migrating to cinder > if they want to use volumes in the Folsom release > > Option 2 -- Deprecate Nova Volume > ================================= > > Process > ------- > * Mark the nova-volume code deprecated but leave it in the project > for the folsom release > * Provide a migration path at folsom > * Backport bugfixes to nova-volume throughout the G-cycle > * Provide a second migration path at G > * Package maintainers can decide when to migrate to cinder > > Disadvantages > ------------- > * Extra maintenance effort > * More confusion about storage in openstack > * More complicated upgrade paths need to be supported > > Personally I think Option 1 is a much more manageable strategy because the > volume code doesn't get a whole lot of attention. I want to keep things > simple and clean with one deployment strategy. My opinion is that if we > choose option 2 we will be sacrificing significant feature development in G in > order to continue to maintain nova-volume for another release. > > But we really need to know if this is going to cause major pain to existing > deployments out there. If it causes a bad experience for deployers we need > to take our medicine and go with option 2. Keep in mind that it shouldn't > make any difference to end users whether cinder or nova-volume is being > used. The current nova-client can use either one. > > Vish > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp