Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>