You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Yoshikazu Nojima <ma...@ynojima.net> on 2014/06/18 08:10:47 UTC
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
Posted by Yoshikazu Nojima <ma...@ynojima.net>.
> 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
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: Review Request 22717: refactor StoragePoolAllocator#filter logic
Posted by Mike Tutkowski <mi...@solidfire.com>.
> 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
Posted by Mike Tutkowski <mi...@solidfire.com>.
> 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
Posted by Yoshikazu Nojima <ma...@ynojima.net>.
> 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
Posted by Mike Tutkowski <mi...@solidfire.com>.
-----------------------------------------------------------
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
>
>