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

John Griffith john.griffith at solidfire.com
Mon Aug 12 19:31:22 UTC 2013


On Mon, Aug 12, 2013 at 1:06 PM, Russell Bryant <rbryant at redhat.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

It's still planned to go in (hopefully in the next day or two [at least the
nova submission should be up]).  There are a couple of fixes under review
on the Cinder side right now and a Nova patch is ready to go once those
merge.  I'll see if we can't get the Nova version uploaded today at least
as a WIP pending the fixes in progress on the Cinder side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130812/32a552ad/attachment.html>


More information about the OpenStack-dev mailing list