Open Stack

On 01/22/2017 04:40 PM, Sylvain Bauza wrote:
> Hey folks,
>
> tl;dr: should we GET /resource_providers for only the related resources
> that correspond to enabled filters ?

No. Have administrators set the allocation ratios for the resources they 
do not care about exceeding capacity to a very high number.

If someone previously removed a filter, that doesn't mean that the 
resources were not consumed on a host. It merely means the admin was 
willing to accept a high amount of oversubscription. That's what the 
allocation_ratio is for.

The flavor should continue to have a consumed disk/vcpu/ram amount, 
because the VM *does actually consume those resources*. If the operator 
doesn't care about oversubscribing one or more of those resources, they 
should set the allocation ratios of those inventories to a high value.

No more adding configuration options for this kind of thing (or in this 
case, looking at an old configuration option and parsing it to see if a 
certain filter is listed in the list of enabled filters).

We have a proper system of modeling these data-driven decisions now, so 
my opinion is we should use it and ask operators to use the placement 
REST API for what it was intended.

Best,
-jay

 > Explanation below why even if I
> know we have a current consensus, maybe we should discuss again about it.
>
>
> I'm still trying to implement https://review.openstack.org/#/c/417961/
> but when trying to get the functional job being +1, I discovered that we
> have at least one functional test [1] asking for just the RAMFilter (and
> not for VCPUs or disks).
>
> Given the current PS is asking for *all* both CPU, RAM and disk, it's
> trampling the current test by getting a NoValidHost.
>
> Okay, I could just modify the test and make sure we have enough
> resources for the flavors but I actually now wonder if that's all good
> for our operators.
>
> I know we have a consensus saying that we should still ask for both CPU,
> RAM and disk at the same time, but I imagine our users coming back to us
> saying "eh, look, I'm no longer able to create instances even if I'm not
> using the CoreFilter" for example. It could be a bad day for them and
> honestly, I'm not sure just adding documentation or release notes would
> help them.
>
> What are you thinking if we say that for only this cycle, we still try
> to only ask for resources that are related to the enabled filters ?
> For example, say someone is disabling CoreFilter in the conf opt, then
> the scheduler shouldn't ask for VCPUs to the Placement API.
>
> FWIW, we have another consensus about not removing
> CoreFilter/RAMFilter/MemoryFilter because the CachingScheduler is still
> using them (and not calling the Placement API).
>
> Thanks,
> -Sylvain
>
> [1]
> https://github.com/openstack/nova/blob/de0eff47f2cfa271735bb754637f979659a2d91a/nova/tests/functional/test_server_group.py#L48
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>