Open Stack

On 07/17/2012 05:47 AM, Thomas, Duncan wrote:
> Jay Pipes on 16 July 2012 18:31 wrote:
>  
>> On 07/16/2012 09:55 AM, David Kranz wrote:
> 
> 
>> Sure, although in this *particular* case the Cinder project is a
>> bit-for-bit copy of nova-volumes. In fact, the only thing really of
>> cause for concern are:
>>
>> * Providing a migration script for the database tables currently in the
>> Nova database to the Cinder database
>> * Ensuring that Keystone's service catalog exposes the volume endpoint
>> along with the compute endpoint so that volume API calls are routed to
>> the right endpoint (and there's nothing preventing a simple URL rewrite
>> redirect for the existing /volumes calls in the Compute API to be
>> routed
>> directly to the new Volumes endpoint which has the same API
> 
> Plus stand up a new rabbit HA server. 

Why? This has nothing to do with the nova-volumes -> Cinder move...

> Plus stand up a new HA database server. 

This is up to you. Technically, you could use the same database server
as Nova and point your Cinder service to it (exactly like you do for
nova-volumes, which queries the Nova database for volume information).
You could gradually move the data to another database server over time,
but it's not required at the time you transition to Cinder.

> Plus understand the new availability constraints of the nova<->cinder interface point

You can act like Cinder is just nova-volumes and not really change
anything in your environment at all. Wherever you are installing the
nova-volume daemon now, you would be installing Cinder. You can decide
to "understand the availability constraints" at some future point.

> And there are bug fixes and correctness fixes slowly going into Cinder, so it is not a bit--for-bit copy any longer...

This whole conversation has been about whether to continue applying
patches to **both** nova-volumes and Cinder. We are trying to avoid
doing that for an extended period of time because it is a pain.

Look, software changes over time. It's not a static thing. We're trying
to discuss the transition from an internal nova-volumes to an external
volume service, but let's not go overboard in making the transition out
to be more than it actually is...

Best,
-jay