diff --git a/TODO b/TODO index d23b8d3..9653518 100644 --- a/TODO +++ b/TODO @@ -1,9 +1,16 @@ -High Priority / Blockers: +High Priority / Blockers for v1.0; -* serial server-side listener/dispatcher +* serial server-side listener/dispatcher. This will allows the + source VM name to be known and passed as part of the fencing + request to the appropriate backend. * pacemaker backend +* ability to pass the hostname, VM name, or VM UUID of the requesting + node to the backend. This will allow better controls of who can + fence who (for example, "vm1 vm2 vm3" can all fence each other, while + none may fence "vm4 vm5 vm6" since they are in a different cluster). + Future Stuff: * oVirt backend diff --git a/fence_virt.txt b/fence_virt.txt index b64cd93..9123708 100644 --- a/fence_virt.txt +++ b/fence_virt.txt @@ -14,10 +14,12 @@ Requirements 3. Nonrequirement of host clustering software. Multiple layers of configuration sucks. While I fundamentally disagree with the general idea that running CMAN on the host constitutes a "heavyweight - cluster", customer perception is important. + cluster", perception is important. -4. Support for RHEV-M. Be able to send fencing requests up to RHEV-M - for execution. This is beneficial from a security standpoint. +4. Ability to support RHEV-M, oVirt server, and other virtual machine + management technologies. This is beneficial from a security standpoint + since it is assumed the management server will be aware of what VMs + are allowed to fence what other VMs. 5. Upgrade compatibility with fence_xvm from a configuration standpoint. This may be provided by a symlink over fence_xvm. If this feature @@ -108,6 +110,7 @@ We propose at 5 plugins in this case: responsible for taking the appropriate action and responding to the request. + These plugins have no requirements on which guest to host communication plugin is used (you could, if you wanted, use 'direct serial' with 'cluster checkpoint', or 'multicast' with 'RHEV-H' for example).