It would seem that those voting for option 1 do so primarily from a code
hygiene and maintenance perspective. If code hygiene were the only issue this
would make sense.
But for those of us with a production environment going straight from
Nova-volumes to a full Cinder deployment is too big a step.
From an operational perspective integrating multiple new things at the same
time is too high risk. Not only does all of the code have to work together but
all of the operational services for standing up a Cinder production service
need to be in place and working. This is too risky for people with services in
production.
I believe we need to have an approach that provides a migration path that will
allow systems in production migrate from Nova-volumes in Folsom to a Cinder
based production in a reliable and incremental way.
From HP’s perspective we need option #2.
I think the code maintenance issue can me ameliorated by just freezing the
Nova-Volumes code in Folsom. This will incentivize people to move off it, but
will allow them to do it in a way that supports production services.
Tim
From: openstack-bounces+tim.reddin=hp@lists.launchpad.net
[mailto:openstack-bounces+tim.reddin=hp@lists.launchpad.net] On Behalf Of
Shake Chen
Sent: 12 July 2012 01:31
To: Renuka Apte
Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
option 1.
On Thu, Jul 12, 2012 at 7:10 AM, Renuka Apte
renuka.a...@citrix.commailto:renuka.a...@citrix.com wrote:
It would be great if anyone who is already deploying Openstack, even if in
non-production environments, could give cinder a try.
For a test environment, it seems easy enough to make the switch using devstack
(I have verified this with XenServer, and I believe, John and folks at
Rackspace have tried on KVM).
Of course, only when more people start trying it will we get a realistic
picture.
Thanks,
Renuka.
From: Flavia Missi [mailto:flaviami...@gmail.commailto:flaviami...@gmail.com]
Sent: Wednesday, July 11, 2012 12:56 PM
To: Renuka Apte
Cc: Vishvananda Ishaya; Openstack
(openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net)
(openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
For me it's +1 to 1, but...
Here at Globo.com we're already deploying clouds based on openstack (not in
production yet, we have dev and lab), and it's really painful when openstack
just forces us to change, I mean, sysadmins are not that happy, so I think
it's more polite if we warn them in Folsom, and remove everything next. Maybe
this way nobody's going to fear the update. It also make us lose the chain of
thought.. you're learning, and suddenly you have to change something for an
update, and then you come back to what you we're doing...
Anyway... :)
Thanks,
On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte
renuka.a...@citrix.commailto:renuka.a...@citrix.com wrote:
+1 for 1
On 11/07/12 8:26 AM, Vishvananda Ishaya
vishvana...@gmail.commailto:vishvana...@gmail.com wrote:
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
