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'...)
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
