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

[Itamar Heim]

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

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