Open Stack

Hi Dilip,

I see.  If thin_provisioning is true and max_over_subscription_ratio is valid, the scheduler will treat it as thin provisioning.  We do not prevent driver from reporting both thin and thick support to be true.  However, I think we need to make a change.

I suggest that you have one pool for thin and the other one for thick but don't report both thin and thick support from the same pool.  That will avoid this problem.

Another possible alternative is to require thin/thick provisioning to be in extra specs and use that info in the scheduler, however that will be a new requirement that affects everyone.  So I am not in favor of that approach.

Can you use one pool for thin and another for thick in your testing?

Thanks,
Xing



> On Feb 12, 2016, at 12:05 AM, Dilip Sunkum Manjunath <Dilip.SunkumManjunath at toshiba-tsip.com> wrote:
> 
> max_over_subscription_ratio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 7749 bytes
Desc: image003.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160212/0da3cbd6/attachment.png>