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

[Eli Mesika]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, "Simon Grinberg"
> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
> Sent: Friday, November 9, 2012 10:38:41 AM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
> 
> 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?

Yes

> 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").

Currently, this default is only reflected in the BLL , but you are right, we should add a new configuration value per version that will have the default value, then we can be backward compatible and support the new default value for 3.2. 
I will add this to the design

> 
>  > 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?).

I had talked with that with Simon, there is no requirement for a proxy list per agent type.
The RFE of supporting secondary agent per Host is orthogonal to this RFE as well
> 
> 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

OK, see my comments above...

> 
>  > 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)

Agree, this will be much simpler ...
Simon, if you have no objection to that, I will change it to support only engine,cluster,datacenter for now...

> 
>  > 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'...)

vdsm has some logic that maps between the call passed to it from engine and the actual parameters generated for the script.
AFAIK, this logic only "builds" the correct arguments for the command according to the agent type 

>