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