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

Yair Zaslavsky yzaslavs at redhat.com
Sun Nov 11 12:27:06 UTC 2012



----- 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?



> 
> 
> >
> > 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
> 



More information about the Devel mailing list