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

Trying to answer open questions + provide feedback -1. We need to change the term Power Management, we only do fencing here so why not call it by name, it may confuse with real power modes management that we'll probably do via VDSM and not via OOB management. Especially as some of the devices external to the host can only do fencing anyhow. I'll change the requirement page, to reflect that + I'll split the proxy from dual card support, as the design should. -2. Default value should be 'cluster, dc, engine' not the other way around. Actually most users I've been talking to will just use 'cluster' since this matches the classic cluster definition where host could only be fenced by another host in the cluster. I'll change requirements to reflect that. -3. The directly selected hosts comes to accommodate two use cases: -3.1- Switch failure - if the fence network for hosts in a DC/Cluster have to split between two switches. Then you will prefer to use hosts that are for sure on the other switch -3.2- Legacy clusters merged into larger clusters due to a move to oVirt then the infrastructural may still fit to the legacy connectivity - lot's of firewalls rules or direct connections that limit access to fencing devices to specific hosts. -3.3- Clustered applications within the VMs, you only want your pears to be allowed to fence you. This is limited for VMs running on specific host group (affinity management that we don't have yet, but we can lock VMs to specific hosts). Note that the above was not meant to accommodate any random server, just hosts in the setup, hosts that already run VDSM. Meaning that maybe instead of the FQDN we can just use hostname - so the UUID will be registered in the tables I don't why it's so complex, if a host provided is removed from the system you either get a canDoAction to remove it from the configuration as well (or a warning that this will remove the host from the fencing configuration). Your only risk if all of them are removed, then you need to set the exclamation mark again (power management is not configured for this host) - 4. Assumption that every host will have all elements is wrong. In the requirement page I've gave combinations where it isn't. Like said there are use cases where you don't want to diverge from hosts in the same cluster. Reason is that if the last host in the cluster (assuming clustered VMs running on this host) you may actually prefer it won't be fenced. Similar to -3.3- - 5. Thinking about it more, Though the chain is more generic and flexible, I would like to return to my original suggestion, of having just primary and secondary proxy: Primary Proxy 1 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host / RHEV Manager / Named host out of the list of all the hosts I think is simpler as far as a user is concerned and it's simpler for us to implement two fields single value in each. And I don't believe we really need more, even in the simple case of cluster only hosts, for clusters larger then 4 hosts by the time you get to the secondary it may be too late. Secondary is more critical for the 'Named host' option or small clusters. I'll look at it some more later today, but sending now to get as much feedback as possible. Regards, Simon ----- Original Message -----