[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