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
<http://solidfire.com/solution/overview/?video=play>*™*
