5:37 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Simon Grinberg" <simon(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Monday, November 12, 2012 12:21:57 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
On 11/12/2012 12:01 PM, Simon Grinberg wrote:
>
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken(a)redhat.com>
>> To: "Eli Mesika" <emesika(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>> Sent: Monday, November 12, 2012 11:47:14 AM
>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
>> selection algorithm for Power Management operations
>>
>> On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>>> To: "Itamar Heim" <iheim(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
>>>>> To: "Eli Mesika" <emesika(a)redhat.com>
>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>,
"Michael
>>>>> Pasternak"
>>>>> <mpastern(a)redhat.com>, "Simon Grinberg"
>>>>> <sgrinber(a)redhat.com>, "Dan Kenigsberg"
<danken(a)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
>>>
>>> danken, what do you think ?
>>
>> BTW, no one has promised the the fence script is implemented in
>> Python
>>
>> $ file `which fence_ipmilan `
>> /usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
>
> PS, if it's really that complex I don't see the a big issue
> dropping engine fence
> It is mostly useful when you have small number of hosts, or
> collection of small clusters where the admin limits the hosts that
> are allowed to fence to cluster hosts and as a failsafe the
> 'engine'
Not sure if this is that complex, I would personally be glad to get more information on
the nature of these fence scripts.
Basically, we have several "patterns" for external invocation:
a. Use ScriptEngine - but we must know the type
b. Exec process
c. JNI/JNA
And - in many java enterprise applications options A and C are implemented on a separate
Java process (if it crashes, the jvm that runs the enterprise application does not crash)
- but I don't think this approach is viable for 3.2.
>
> *It does however solves at the same time the issue that we (still)
> can't 'Approve a host have been rebooted' if it's the last host in
> the DC since the path goes through the fencing logic.
exactly, we need to allow engine fence to solve the single/last host
private case.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel