Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 11:22:29 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 10:52:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 05:45 PM, Simon Grinberg wrote: 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 peers 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). that's VMs asking to fence (stop) other VMs, not hosts. why are you mixing it with host fencing? What happens if the host on which the peer VM is down? You need to fence the host. I was thinking about preventing a race where the VM asks to fence it's peer while the engine fences the host. In this case the fence of the peer VM may be reported as failed (no option to send stop to the VM) while the host status is yet unknown, or worse may succeed after the host rebooted killing the VM again after it restarted. To prevent that you request to fence the host instead of fencing the VM a. But you are right that it does not matter which host will do the fencing, I was thinking on the old stile infra. 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) because this was a text field, and i don't like code having to know to check some obscure field and parse it for dependencies. relations between entities are supposed to be via db referential integrity if possible (we had some locking issues with these). i prefer implementation will start with the more simple use case not covering these complexities. - 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. this is a bit simpler. but as for specifying a specific host: - now you are asking to check two fields (proxy1, proxy2) - probably to also alert if all these hosts moved to maint, or when moving them to another cluster, etc. - it doesn't cover the use case of splitting between switches, sub clusters, etc. as you are limited to two hosts, which may have been moved to maint/shutdown for power saving, etc. (since you are using a static host assignment, rather than an implied group of hosts (cluster, dc, engine) Are you offering to allow defining hosts-groups? :). I'll be happy if you do, we really need that for some cases of the affinity feature. Especially
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 11:47:14 AM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... PS, if it's really that complex I don't see the a big issue dropping engine fence It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine' *It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/12/2012 12:01 PM, Simon Grinberg wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 11:47:14 AM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... PS, if it's really that complex I don't see the a big issue dropping engine fence It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine' *It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic. exactly, we need to allow engine fence to solve the single/last host private case. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 12:21:57 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/12/2012 12:01 PM, Simon Grinberg wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 11:47:14 AM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... PS, if it's really that complex I don't see the a big issue dropping engine fence It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine' *It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic. exactly, we need to allow engine fence to solve the single/last host private case. Indeed ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 11:47:14 AM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python Hmm, in this case, maybe we should invoke the script as process from JVM (ugly, but ScriptEngine, or Eli's suggestion will not work unless we know the type of the script). $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 12:21:57 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/12/2012 12:01 PM, Simon Grinberg wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, November 12, 2012 11:47:14 AM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? BTW, no one has promised the the fence script is implemented in Python $ file `which fence_ipmilan ` /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable... PS, if it's really that complex I don't see the a big issue dropping engine fence It is mostly useful when you have small number of hosts, or collection of small clusters where the admin limits the hosts that are allowed to fence to cluster hosts and as a failsafe the 'engine' Not sure if this is that complex, I would personally be glad to get more information on the nature of these fence scripts. Basically, we have several patterns for external invocation: a. Use ScriptEngine - but we must know the type b. Exec process c. JNI/JNA And - in many java enterprise applications options A and C are implemented on a separate Java process (if it crashes, the jvm that runs the enterprise application does not crash) - but I don't think this approach is viable for 3.2. *It does however solves at the same time the issue that we (still) can't 'Approve a host have been rebooted' if it's the last host in the DC since the path goes through the fencing logic. exactly, we need to allow engine fence to solve the single/last host private case. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Saggi has had a nascent attempt to factor the little logic we have out http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py AFAIR there's nothing there beyond: - log everything but passwords, - build the input stream, - run the script - convert its return code and there's also killing dormant scripts on vdsm exist (which I find not important at all). Dan. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 01:27 PM, Dan Kenigsberg wrote: On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Saggi has had a nascent attempt to factor the little logic we have out http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py AFAIR there's nothing there beyond: - log everything but passwords, - build the input stream, - run the script - convert its return code and there's also killing dormant scripts on vdsm exist (which I find not important at all). if the wrapping isn't doing anything but calling the scripts, then doing it again from java isn't an issue. it's only an issue if there is any business logic in the wrapping. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 01:18 PM, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java if this is JNI, i think it won't fly for engine. JNA may be viable. or just shell launch danken, what do you think ? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Eli Mesika emes...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:18:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java danken, what do you think ? Hi, JDK 6 (and above) has a ScriptEngine. I would suggest using this JSR. For example, look at - http://www.alittlemadness.com/2008/07/15/java-6-using-python-via-the-new-scripting-engine/ What kinda bothers me is the fact that both your link, the link I provided use Jython, and not Python - i.e the script itself has to run over the jvm. We should see if the JVM allows us to run the fencing script (no JVM restrictions). It's kinda surprising to me - I was sure that ScriptEngine can run Python (i.e - on the linux machine itself) and not Jython. I will continue checking. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 01:18 PM, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java if this is JNI, i think it won't fly for engine. JNA may be viable. or just shell launch Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)? Am I missing something else here? danken, what do you think ? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 02:27 PM, Yair Zaslavsky wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 01:18 PM, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java if this is JNI, i think it won't fly for engine. JNA may be viable. or just shell launch Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)? Am I missing something else here? you are not missing, it's about JNI from JEE danken, what do you think ? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Itamar Heim ih...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Eli Mesika emes...@redhat.com Sent: Sunday, November 11, 2012 2:30:00 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 02:27 PM, Yair Zaslavsky wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 01:18 PM, Eli Mesika wrote: - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. I'll check it with danken on SUN Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter See http://stackoverflow.com/questions/8898765/calling-python-in-java if this is JNI, i think it won't fly for engine. JNA may be viable. or just shell launch Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)? Am I missing something else here? you are not missing, it's about JNI from JEE Hmm... now that I remember our previous JNA adventure , and after looking at some resources, I'm staring to think whether JNA code is really safer (not talking about the ease of development here). I started digging at JNA code -and JNA is actually JNI (i.e - uses native methods) based framework (infra to ease native code development) - So one can say it relies on the fact this is open source and used by various comments, but at the end - this is still JNI behind the scene (see jna/src/com/sun/jna/Native.java) Bugs still can occur at JNA code (maybe less, as it's supposed to be cleaner code) - but if there are bugs, JVM crashes. danken, what do you think ? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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 - From: Eli Mesika emes...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:18:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, Simon Grinberg sgrin...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/09/2012 10:52 AM, Eli Mesika wrote: 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
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Simon Grinberg si...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Dan Kenigsberg dan...@redhat.com Sent: Sunday, November 11, 2012 5:45:41 PM Subject: 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. This was already done: http://wiki.ovirt.org/wiki/Features/Design/HostPMProxyPreferences http://wiki.ovirt.org/wiki/Features/Design/HostPMMultipleAgents Have to move, will comment on other issues later on, please modify the new slitted wiki pages -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 - From: Eli Mesika emes...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 1:18:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Eli Mesika emes...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations - Original Message - From: Itamar Heim ih...@redhat.com To: Eli Mesika emes...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Michael Pasternak
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 05:45 PM, Simon Grinberg wrote: 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 peers 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). that's VMs asking to fence (stop) other VMs, not hosts. why are you mixing it with host fencing? 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) because this was a text field, and i don't like code having to know to check some obscure field and parse it for dependencies. relations between entities are supposed to be via db referential integrity if possible (we had some locking issues with these). i prefer implementation will start with the more simple use case not covering these complexities. - 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. this is a bit simpler. but as for specifying a specific host: - now you are asking to check two fields (proxy1, proxy2) - probably to also alert if all these hosts moved to maint, or when moving them to another cluster, etc. - it doesn't cover the use case of splitting between switches, sub clusters, etc. as you are limited to two hosts, which may have been moved to maint/shutdown for power saving, etc. (since you are using a static host assignment, rather than an implied group of hosts (cluster, dc, engine) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
- Original Message - From: Itamar Heim ih...@redhat.com To: Simon Grinberg si...@redhat.com Cc: Eli Mesika emes...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Sunday, November 11, 2012 10:52:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations On 11/11/2012 05:45 PM, Simon Grinberg wrote: 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 peers 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). that's VMs asking to fence (stop) other VMs, not hosts. why are you mixing it with host fencing? What happens if the host on which the peer VM is down? You need to fence the host. I was thinking about preventing a race where the VM asks to fence it's peer while the engine fences the host. In this case the fence of the peer VM may be reported as failed (no option to send stop to the VM) while the host status is yet unknown, or worse may succeed after the host rebooted killing the VM again after it restarted. To prevent that you request to fence the host instead of fencing the VM a. But you are right that it does not matter which host will do the fencing, I was thinking on the old stile infra. 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) because this was a text field, and i don't like code having to know to check some obscure field and parse it for dependencies. relations between entities are supposed to be via db referential integrity if possible (we had some locking issues with these). i prefer implementation will start with the more simple use case not covering these complexities. - 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. this is a bit simpler. but as for specifying a specific host: - now you are asking to check two fields (proxy1, proxy2) - probably to also alert if all these hosts moved to maint, or when moving them to another cluster, etc. - it doesn't cover the use case of splitting between switches, sub clusters, etc. as you are limited to two hosts, which may have been moved to maint/shutdown for power saving, etc. (since you are using a static host assignment, rather than an implied group of hosts (cluster, dc, engine) Are you offering to allow defining hosts-groups? :). I'll be happy if you do, we really need that for some cases of the affinity feature. Especially those involving multi-site. Hosts group == A set of named hosts within the same cluster ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/09/2012 10:52 AM, Eli Mesika wrote: 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 can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
