Le 23/01/2017 15:11, Jay Pipes a écrit : > 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. >
I know your point, but please consider mine. What if an operator disabled CoreFilter in Newton and wants to upgrade to Ocata ? All of that implementation being very close to the deadline makes me nervous and I really want the seamless path for operators now using the placement service. Also, like I said in my bigger explanation, we should need to modify a shit ton of assertions in our tests that can say "meh, don't use all the filters, but just these ones". Pretty risky so close to a FF. -Sylvain > 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 __________________________________________________________________________ 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