On Mon, Aug 12, 2013 at 1:06 PM, Russell Bryant <[email protected]> wrote:
> On 08/12/2013 02:56 PM, Vishvananda Ishaya wrote: > > > > On Aug 12, 2013, at 8:55 AM, John Griffith <[email protected] > > <mailto:[email protected]>> 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 > [email protected] > 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.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
