Le 23/01/2017 15:18, Sylvain Bauza a écrit : > > > 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. >
Oh, just discovered a related point : in Devstack, we don't set the CoreFilter by default ! https://github.com/openstack-dev/devstack/blob/adcf0c50cd87c68abef7c3bb4785a07d3545be5d/lib/nova#L94 TBC, that means that the gate is not verifying the VCPUs by the filter, just by the compute claims. Heh. Honestly I think we really need to optionally the filters for Ocata then. -Sylvain > -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 > __________________________________________________________________________ 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