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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
