> On June 26, 2014, 11:46 p.m., Mike Tutkowski wrote: > > I first had a chance to run this patch through a sophisticated test tonight > > and noticed an issue with zone-wide primary storage that's based on the > > iSCSI protocol. > > > > This patch leads to iSCSI storage being filtered out for ROOT volumes, > > which is a legitimate use case in my scenario. > > > > As such, I had to return the filter method to the > > ZoneWideStoragePoolAllocator class. > > > > I left in the other modification to the AbstractStoragePoolAllocator. > > Yoshikazu Nojima wrote: > I thought the root volume filtering logic weird, but I didn't dig into > the problem. > Since this is a good opportunity, I would like to rethink this logic. > which storage requires the root volume filtering logic? > I understand that SolidFire's storage doesn't require it, but what about > other iSCSI storage? > Is there any reason that other iSCSI storage cannot handle a root volume? > Does anyone know? > Even if SolidFire's storage is the only iSCSI storage that can handle a > root volume, I think SolidFire's storage should be exempted from the > filtering logic not because storage is zone wide, but because storage is > SolidFire's. > > > Mike Tutkowski wrote: > I'm pretty sure any vendor's iSCSI storage can handle root volumes as > it's just data placed on a disk. I don't know why that logic is there. > > Any thoughts on how this code ended up in 4.4 and 4.4-forward (since the > review request is just for master)? If that would have went out to the field, > it would have rendered my plug-in completely useless. > > Thanks! > > Yoshikazu Nojima wrote: > Hi Mike, > > What about reverting your latest > commit(12e92e10ffbd9f86ebff11c2a1b22c5bafafb3d1) and removing root disk > filtering logic for iSCSI storage in AbstractStoragePoolAllocator? > If you are OK, I'll make a commit. > > Thanks.
Yeah, no problem. As long as it's only in the master branch, that works. - Mike ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22717/#review46838 ----------------------------------------------------------- On June 18, 2014, 12:10 a.m., Yoshikazu Nojima wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22717/ > ----------------------------------------------------------- > > (Updated June 18, 2014, 12:10 a.m.) > > > Review request for cloudstack, Mike Tutkowski and Prachi Damle. > > > Repository: cloudstack-git > > > Description > ------- > > refactor StoragePoolAllocator#filter logic to enable hypervisor type check, > storage type check for root volume and avoid list check, and to support IOPS > capacity control in a cluster wide storage pool and a local storage pool. > > > Diffs > ----- > > > engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java > ddbb5a4 > > engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java > 8fb9c8d > > Diff: https://reviews.apache.org/r/22717/diff/ > > > Testing > ------- > > > Thanks, > > Yoshikazu Nojima > >
