----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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