[openstack-dev] [OpenStack][Dev] Block Storage libraries and shared code

Russell Bryant rbryant at redhat.com
Mon Aug 12 19:06:54 UTC 2013


On 08/12/2013 02:56 PM, Vishvananda Ishaya wrote:
> 
> On Aug 12, 2013, at 8:55 AM, John Griffith <john.griffith at solidfire.com
> <mailto:john.griffith at solidfire.com>> wrote:
> 
>> Hey,
>>
>> There have been a couple of block storage related patches in Nova
>> lately and I wanted to get some discussion going and also maybe
>> increase some awareness on some efforts that were discussed at the
>> last summit.  To catch up a bit here's the etherpad from the summit
>> session [1].
>>
>> First off, there was a patch to move Nova's LVM code in to OSLO (here
>> [2]).  This one is probably my fault for not having enough awareness
>> out there regarding our plans/goals with brick.  I'd like to hear from
>> folks if the brick approach is not sufficient or if there's some other
>> reason that it's not desirable (hopefully it's just that folks didn't
>> know about it). 
>>
>> For reference/review the latest version of the brick/local_dev/lvm
>> code is here: [4].
>>
>> One question we haven't answered on this yet is where this code should
>> ultimately live.  Should it be in OSLO, or should it be a separate
>> library that's part of Cinder and can be imported by other projects.
>>  I'm mixed on this for a number of reasons but I think either approach
>> is fine.
>>
>> The next item around this topic that came up was a patch to add
>> support for using RBD for local volumes in Nova (here [3]).  You'll
>> notice a number of folks mentioned brick on this, and I think that's
>> the correct answer.  At the same time while I think that's the right
>> answer long term I also would hate to see this feature NOT go in to H
>> just because folks weren't aware of what was going on in Brick.  It's
>> a bit late in the cycle so my thought on this is that I'd like to see
>> this resubmitted using the brick/common approach.  If that can't be
>> done between now and the feature freeze for H3 I'd rather see the
>> patch go in as is than have the feature not be present at all for
>> another release.  We can then address this when we get a better story
>> in place for brick.
> 
> It seems like the key question is whether or not the nova code is going
> to be replaced by brick by Havana. If not, then this should go in as-is.

+1.  I was still expecting that it was.  If not, I'm happy to go with this.

What's the status on this work?

https://blueprints.launchpad.net/nova/+spec/refactor-iscsi-fc-brick

-- 
Russell Bryant



More information about the OpenStack-dev mailing list