Le 24/01/2017 22:22, Dan Smith a écrit : >> 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 agree with the above. I think it's extremely counter-intuitive to set > a bunch of over-subscription values only to have them ignored because a > scheduler filter isn't configured. > > If we ignore some of the resources on schedule, the compute nodes will > start reporting values that will make the resources appear to be > negative to anything looking at the data. Before a somewhat-recent > change of mine, the oversubscribed computes would have *failed* to > report negative resources at all, which was a problem for a reconfigure > event. I think the scheduler purposefully forcing computes into the red > is a mistake. > > Further, new users that don't know our sins of the past will wonder why > the nice system they see in front of them isn't doing the right thing. > Existing users can reconfigure allocation ratio values before they > upgrade. We can also add something to our upgrade status tool to warn them. >
It's litterally 2 days before FeatureFreeze and we ask operators to change their cloud right now ? Looks difficult to me and like I said in multiple places by email, we have a ton of assertions saying it's acceptable to have not all the filters. -Sylvain > --Dan > > __________________________________________________________________________ > 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
