Review Request 22717: refactor StoragePoolAllocator#filter logic
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22717/ --- 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
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22717/#review46838 --- 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. - Mike Tutkowski 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 > >
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
> On June 27, 2014, 5:46 a.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. 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. - Yoshikazu --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22717/#review46838 --- On June 18, 2014, 6: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, 6: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 > >
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
> 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. > 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! - 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 > >
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
> On June 27, 2014, 5:46 a.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! 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. - Yoshikazu --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22717/#review46838 --- On June 18, 2014, 6: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, 6: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 > >
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
> 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 > >
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
I found one issue related to this change. I had to amend the logic in the
filter method of AbstractStoragePoolAllocator to include a check for
HypervisorType.Any (otherwise zone-wide storage with the type of Any is
skipped, which is what's happening to me right now):
} else if (pool.getHypervisor() != null &&
!pool.getHypervisor().equals(HypervisorType.Any) && !(pool.getHypervisor()
== dskCh.getHypervisorType())) {
if (s_logger.isDebugEnabled()) {
s_logger.debug("StoragePool does not have required
hypervisorType, skipping this pool");
}
return false;
}
I plan to check this code in later tonight (this is for master only, by the
way).
On Fri, Jun 27, 2014 at 1:30 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
>
>
> > 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
> >
> >
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*
