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: some comments on the Detailed part: 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"). 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 see note above for upgrade wrt default value and backward compatibility 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) 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'...)