----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@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" <danken@redhat.com> To: "Eli Mesika" <emesika@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" <emesika@redhat.com> To: "Itamar Heim" <iheim@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" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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