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

[Yair Zaslavsky]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Eli Mesika" <emesika at 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 at redhat.com>
> >> To: "Eli Mesika" <emesika at redhat.com>
> >> Cc: "engine-devel" <engine-devel at 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 at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at 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 at redhat.com>
> >>>>> To: "Eli Mesika" <emesika at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael
> >>>>> Pasternak"
> >>>>> <mpastern at redhat.com>, "Simon Grinberg"
> >>>>> <sgrinber at redhat.com>, "Dan Kenigsberg" <danken at 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 at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
>