[Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations

[Itamar Heim]

On 11/07/2012 08:43 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed
>
> Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> Detailed Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
>
> DR for this RFE will be next week, exact schedule & place will follow.
>

some comments on the Detailed part:

 > The default value for this column will be : 'engine,cluster,dc'

1. so if this is not passed via REST API, this will be the default value?
2. i didn't see any comment about backward compatibility/upgrade (since 
the default value now is actually "DC", so setting a different default 
will change behavior in upgrade, which it shouldn't).
3. would it make sense to make this default value per compatibility 
version? otherwise, adding a 3.1 host via API in 3.1 and 3.2 will give 
different behavior (since default for this in 3.1 is "DC").

 > API

we also want to allow defining different types of fencing going forward, 
how will the new API support this (proxy list will be per fence type?).

see note above for default value behavior for api backward compatibility 
as well

 > Installation/Upgrade

see note above for upgrade wrt default value and backward compatibility

 > pre-defined values

I'm not sure how important is the random ip/host vs. engine/cluster/dc.
but if you keep it (and change it to configured hosts in the system), 
then you should keep hosts uuid's.
(it adds complexity, since those hosts can be deleted, and if only such 
a host was defined, it leaves another host without PM configured, so 
you'll be asked to add more and more validations.

my 2 cents: supporting "another specific host", rather than 
engine/cluster/dc is adding complexity, and should be given a valid use 
case to justify that complexity (and even if needed, i'd consider doing 
the implementation in two phases)

 > FenceWrapper

i understand danken suggested going this way, rather than than another 
instance of vdsm.
is vdsm only calling these scripts today and all logic is in engine, or 
does vdsm has any logic in wrapping these scripts (not a blocker to 
doing FenceWrapper, just worth extracting that logic from vdsm to such a 
script, then using it in both. i hope answer is 'no logic'...)