Open Stack

On 08/01/2013 09:51 AM, Álvaro López García wrote:
> On Thu 01 Aug 2013 (09:07), Sandy Walsh wrote:
>>
>>
>> On 08/01/2013 04:24 AM, Álvaro López García wrote:
>>> Hi all.
>>>
>>> TL;DR: I've created a blueprint [1] regarding weight normalization.
>>> I would be very glad if somebody could examine and comment it.
>>
>> Something must have changed. It's been a while since I've done anything
>> with the scheduler, but normalized weights is the way it was designed
>> and implemented.
> 
> It seems reasonable, but it is not there anymore:
> 
>     class RAMWeigher(weights.BaseHostWeigher):
>         (...)
>         def _weigh_object(self, host_state, weight_properties):
>             """Higher weights win.  We want spreading to be the default."""
>             return host_state.free_ram_mb

Hmm, that's unfortunate. We use our own weighing functions internally,
so perhaps we were unaffected by this change.

> 
> 
>> The separate Weighing plug-ins are responsible for taking the specific
>> units (cpu load, disk, ram, etc) and converting them into normalized
>> 0.0-1.0 weights. Internally the plug-ins can work however they like, but
>> their output should be 0-1.
> 
> With the current code, this is not true. Anyway, I think this responsability
> should be implemented in the BaseWeightHandler rather than each weigher.
> This way each weigher can return whatever they want, but we will be
> always using a correct value.

I think the problem with moving it to the base handler is that the base
doesn't know the max range of the value ... of course, this could be
passed down. But yeah, we wouldn't want to duplicate the normalization
code itself in every function.

>> The multiplier, however, could scale this outside that range (if disk is
>> more important than cpu, for example).
> 
> Yes, of course, since the multiplier is applied *after* normalizing the
> weights.
> 
>> Actually, I remember it being offset + scale * weight, so you could put
>> certain factors in bands: cpu: 1000+, disk: 10000+, etc. Hopefully
>> offset is still there too?
> 
> No, it is not.

poop. You may want to consider adding it back. Offset + Scale * Weight
allows for many more weighing constructs.

> 
> Thanks,
>