----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Eli Mesika" <emesika@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" <iheim@redhat.com> To: "Eli Mesika" <emesika@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" <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
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