[Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
1:43 p.m.
Hi
Please review , any comments are welcomed
Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
Detailed Design :
http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
DR for this RFE will be next week, exact schedule & place will follow.
Thanks
Eli
9:25 a.m.
On 11/07/2012 08:43 PM, Eli Mesika wrote:
Hi
Please review , any comments are welcomed
Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
Detailed Design :
http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
DR for this RFE will be next week, exact schedule & place will follow.
1. what's the logic on deciding to move to next proxy ? is it per action
(restart being comprised of stop and start. can the stop and start
happen from different proxies)?
2. I'm guessing for 'engine' as proxy, vdsm will be installed with
engine on same host.
is the plan to teat it as a separate instance of vdsm, listening on a
separate port, or to assume an all-in-one deployment always?
if it is added as a host, just for fencing, it requires special
treatment for that host. while if added as a separate instance (on a
different tcp port), it doesn't have to be defined as a host in the system.
iirc, we can install vdsm, and launch multiple instances of it (at least
we could in the past).
3. i didn't understand the fqdn/ip proxy mode, if it is not an existing
host in the system, how will engine communicate with it over secure
xml/rpc? (i can understand selecting a specific host, but not a text box
for fqdn/ip).
thanks,
Itamar
10:09 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Dan Kenigsberg"
<danken(a)redhat.com>
Sent: Thursday, November 8, 2012 5:25:48 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
On 11/07/2012 08:43 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed
>
> Requirements :
> http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> Detailed Design :
> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
>
> DR for this RFE will be next week, exact schedule & place will
> follow.
1. what's the logic on deciding to move to next proxy ? is it per
action
(restart being comprised of stop and start. can the stop and start
happen from different proxies)?
Yes, it is per action so stop & start may use different proxies.
2. I'm guessing for 'engine' as proxy, vdsm will be installed with
engine on same host.
is the plan to teat it as a separate instance of vdsm, listening on a
separate port, or to assume an all-in-one deployment always?
if it is added as a host, just for fencing, it requires special
treatment for that host. while if added as a separate instance (on a
different tcp port), it doesn't have to be defined as a host in the
system.
iirc, we can install vdsm, and launch multiple instances of it (at
least
we could in the past).
we have 3 options here
1) VDSM instance
2) Lightweight VDSM (with only PM abilities)
3) Accessing the fenece-agents package scripts directly
I have talked with danken , he think we should apply 3)
3. i didn't understand the fqdn/ip proxy mode, if it is not an
existing
host in the system, how will engine communicate with it over secure
xml/rpc? (i can understand selecting a specific host, but not a text
box
for fqdn/ip).
Good point, I will change the design accordingly
thanks,
Itamar
2:38 a.m.
On 11/07/2012 08:43 PM, Eli Mesika wrote:
Hi
Please review , any comments are welcomed
Requirements : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
Detailed Design :
http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
DR for this RFE will be next week, exact schedule & place will follow.
some comments on the Detailed part:
The default value for this column will be :
'engine,cluster,dc'
1. so if this is not passed via REST API, this will be the default value?
2. i didn't see any comment about backward compatibility/upgrade (since
the default value now is actually "DC", so setting a different default
will change behavior in upgrade, which it shouldn't).
3. would it make sense to make this default value per compatibility
version? otherwise, adding a 3.1 host via API in 3.1 and 3.2 will give
different behavior (since default for this in 3.1 is "DC").
API
we also want to allow defining different types of fencing going forward,
how will the new API support this (proxy list will be per fence type?).
see note above for default value behavior for api backward compatibility
as well
Installation/Upgrade
see note above for upgrade wrt default value and backward compatibility
pre-defined values
I'm not sure how important is the random ip/host vs. engine/cluster/dc.
but if you keep it (and change it to configured hosts in the system),
then you should keep hosts uuid's.
(it adds complexity, since those hosts can be deleted, and if only such
a host was defined, it leaves another host without PM configured, so
you'll be asked to add more and more validations.
my 2 cents: supporting "another specific host", rather than
engine/cluster/dc is adding complexity, and should be given a valid use
case to justify that complexity (and even if needed, i'd consider doing
the implementation in two phases)
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'...)
3:52 a.m.
----- 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 10:38:41 AM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
On 11/07/2012 08:43 PM, Eli Mesika wrote:
> Hi
>
> Please review , any comments are welcomed
>
> Requirements :
> http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences
> Detailed Design :
> http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences
>
> DR for this RFE will be next week, exact schedule & place will
> follow.
>
some comments on the Detailed part:
> The default value for this column will be : 'engine,cluster,dc'
1. so if this is not passed via REST API, this will be the default
value?
Yes
2. i didn't see any comment about backward compatibility/upgrade
(since
the default value now is actually "DC", so setting a different
default
will change behavior in upgrade, which it shouldn't).
3. would it make sense to make this default value per compatibility
version? otherwise, adding a 3.1 host via API in 3.1 and 3.2 will
give
different behavior (since default for this in 3.1 is "DC").
Currently, this default is only reflected in the BLL , but you are right, we should add a
new configuration value per version that will have the default value, then we can be
backward compatible and support the new default value for 3.2.
I will add this to the design
> API
we also want to allow defining different types of fencing going
forward,
how will the new API support this (proxy list will be per fence
type?).
I had talked with that with Simon, there is no requirement for a proxy list per agent
type.
The RFE of supporting secondary agent per Host is orthogonal to this RFE as well
see note above for default value behavior for api backward
compatibility
as well
> Installation/Upgrade
see note above for upgrade wrt default value and backward
compatibility
OK, see my comments above...
> pre-defined values
I'm not sure how important is the random ip/host vs.
engine/cluster/dc.
but if you keep it (and change it to configured hosts in the system),
then you should keep hosts uuid's.
(it adds complexity, since those hosts can be deleted, and if only
such
a host was defined, it leaves another host without PM configured, so
you'll be asked to add more and more validations.
my 2 cents: supporting "another specific host", rather than
engine/cluster/dc is adding complexity, and should be given a valid
use
case to justify that complexity (and even if needed, i'd consider
doing
the implementation in two phases)
Agree, this will be much simpler ...
Simon, if you have no objection to that, I will change it to support only
engine,cluster,datacenter for now...
> 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
4:02 a.m.
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.
4:06 a.m.
----- 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
5:18 a.m.
----- 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 ?
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:45 a.m.
On 11/11/2012 01:18 PM, 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
if this is JNI, i think it won't fly for engine.
JNA may be viable.
or just shell launch
danken, what do you think ?
>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
6:27 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)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(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
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:30 a.m.
On 11/11/2012 02:27 PM, Yair Zaslavsky wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Eli Mesika" <emesika(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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(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
>
> 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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
7:09 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eli Mesika"
<emesika(a)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(a)redhat.com>
>> To: "Eli Mesika" <emesika(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)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(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
>>
>> 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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
6:23 a.m.
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, November 11, 2012 1:18:53 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
----- 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 ?
Hi,
JDK 6 (and above) has a ScriptEngine.
I would suggest using this JSR.
For example, look at -
http://www.alittlemadness.com/2008/07/15/java-6-using-python-via-the-new-...
What kinda bothers me is the fact that both your link, the link I provided use Jython, and
not Python - i.e the script itself has to run over the jvm.
We should see if the JVM allows us to run the fencing script (no JVM restrictions).
It's kinda surprising to me - I was sure that ScriptEngine can run Python (i.e - on
the linux machine itself) and not Jython.
I will continue checking.
>
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:45 a.m.
Trying to answer open questions + provide feedback
-1. We need to change the term Power Management, we only do fencing here so why not call
it by name, it may confuse with real power modes management that we'll probably do via
VDSM and not via OOB management. Especially as some of the devices external to the host
can only do fencing anyhow.
I'll change the requirement page, to reflect that + I'll split the proxy from dual
card support, as the design should.
-2. Default value should be 'cluster, dc, engine' not the other way around.
Actually most users I've been talking to will just use 'cluster' since this
matches the classic cluster definition where host could only be fenced by another host in
the cluster.
I'll change requirements to reflect that.
-3. The directly selected hosts comes to accommodate two use cases:
-3.1- Switch failure - if the fence network for hosts in a DC/Cluster have to split
between two switches. Then you will prefer to use hosts that are for sure on the other
switch
-3.2- Legacy clusters merged into larger clusters due to a move to oVirt then the
infrastructural may still fit to the legacy connectivity - lot's of firewalls rules or
direct connections that limit access to fencing devices to specific hosts.
-3.3- Clustered applications within the VMs, you only want your pears to be allowed to
fence you. This is limited for VMs running on specific host group (affinity management
that we don't have yet, but we can lock VMs to specific hosts).
Note that the above was not meant to accommodate any random server, just hosts in the
setup, hosts that already run VDSM.
Meaning that maybe instead of the FQDN we can just use hostname - so the UUID will be
registered in the tables
I don't why it's so complex, if a host provided is removed from the system you
either get a canDoAction to remove it from the configuration as well (or a warning that
this will remove the host from the fencing configuration). Your only risk if all of them
are removed, then you need to set the exclamation mark again (power management is not
configured for this host)
- 4. Assumption that every host will have all elements is wrong. In the requirement page
I've gave combinations where it isn't.
Like said there are use cases where you don't want to diverge from hosts in the
same cluster. Reason is that if the last host in the cluster (assuming clustered VMs
running on this host) you may actually prefer it won't be fenced. Similar to -3.3-
- 5. Thinking about it more, Though the chain is more generic and flexible, I would like
to return to my original suggestion, of having just primary and secondary proxy:
Primary Proxy 1 => Drop down -> Any cluster host / Any DC host / RHEV Manager /
Named host out of the list of all the hosts
Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host / RHEV Manager
/ Named host out of the list of all the hosts
I think is simpler as far as a user is concerned and it's simpler for us to
implement two fields single value in each. And I don't believe we really need more,
even in the simple case of cluster only hosts, for clusters larger then 4 hosts by the
time you get to the secondary it may be too late. Secondary is more critical for the
'Named host' option or small clusters.
I'll look at it some more later today, but sending now to get as much feedback as
possible.
Regards,
Simon
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, November 11, 2012 1:18:53 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
----- 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 ?
>
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:24 a.m.
----- Original Message -----
From: "Simon Grinberg" <simon(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Dan Kenigsberg"
<danken(a)redhat.com>
Sent: Sunday, November 11, 2012 5:45:41 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
Trying to answer open questions + provide feedback
-1. We need to change the term Power Management, we only do fencing
here so why not call it by name, it may confuse with real power
modes management that we'll probably do via VDSM and not via OOB
management. Especially as some of the devices external to the host
can only do fencing anyhow.
I'll change the requirement page, to reflect that + I'll split the
proxy from dual card support, as the design should.
This was already done:
http://wiki.ovirt.org/wiki/Features/Design/HostPMProxyPreferences
http://wiki.ovirt.org/wiki/Features/Design/HostPMMultipleAgents
Have to move, will comment on other issues later on, please modify the new slitted wiki
pages
-2. Default value should be 'cluster, dc, engine' not the other way
around. Actually most users I've been talking to will just use
'cluster' since this matches the classic cluster definition where
host could only be fenced by another host in the cluster.
I'll change requirements to reflect that.
-3. The directly selected hosts comes to accommodate two use cases:
-3.1- Switch failure - if the fence network for hosts in a
DC/Cluster have to split between two switches. Then you will
prefer to use hosts that are for sure on the other switch
-3.2- Legacy clusters merged into larger clusters due to a move to
oVirt then the infrastructural may still fit to the legacy
connectivity - lot's of firewalls rules or direct connections
that limit access to fencing devices to specific hosts.
-3.3- Clustered applications within the VMs, you only want your
pears to be allowed to fence you. This is limited for VMs running
on specific host group (affinity management that we don't have
yet, but we can lock VMs to specific hosts).
Note that the above was not meant to accommodate any random
server, just hosts in the setup, hosts that already run VDSM.
Meaning that maybe instead of the FQDN we can just use hostname -
so the UUID will be registered in the tables
I don't why it's so complex, if a host provided is removed from
the system you either get a canDoAction to remove it from the
configuration as well (or a warning that this will remove the
host from the fencing configuration). Your only risk if all of
them are removed, then you need to set the exclamation mark again
(power management is not configured for this host)
- 4. Assumption that every host will have all elements is wrong. In
the requirement page I've gave combinations where it isn't.
Like said there are use cases where you don't want to diverge from
hosts in the same cluster. Reason is that if the last host in the
cluster (assuming clustered VMs running on this host) you may
actually prefer it won't be fenced. Similar to -3.3-
- 5. Thinking about it more, Though the chain is more generic and
flexible, I would like to return to my original suggestion, of
having just primary and secondary proxy:
Primary Proxy 1 => Drop down -> Any cluster host / Any DC host /
RHEV Manager / Named host out of the list of all the hosts
Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host
/ RHEV Manager / Named host out of the list of all the hosts
I think is simpler as far as a user is concerned and it's
simpler for us to implement two fields single value in each.
And I don't believe we really need more, even in the simple
case of cluster only hosts, for clusters larger then 4 hosts by
the time you get to the secondary it may be too late. Secondary
is more critical for the 'Named host' option or small clusters.
I'll look at it some more later today, but sending now to get as much
feedback as possible.
Regards,
Simon
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: "Dan Kenigsberg" <danken(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, November 11, 2012 1:18:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> selection algorithm for Power Management operations
>
>
>
> ----- 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 ?
>
> >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
2:52 p.m.
On 11/11/2012 05:45 PM, Simon Grinberg wrote:
3. The directly selected hosts comes to accommodate two use cases:
-3.1- Switch failure - if the fence network for hosts in a DC/Cluster have to split
between two switches. Then you will prefer to use hosts that are for sure on the other
switch
-3.2- Legacy clusters merged into larger clusters due to a move to oVirt then the
infrastructural may still fit to the legacy connectivity - lot's of firewalls rules or
direct connections that limit access to fencing devices to specific hosts.
-3.3- Clustered applications within the VMs, you only want your peers to be allowed
to fence you. This is limited for VMs running on specific host group (affinity management
that we don't have yet, but we can lock VMs to specific hosts).
that's VMs asking to fence (stop) other VMs, not hosts. why are you
mixing it with host fencing?
Note that the above was not meant to accommodate any random server, just hosts in the
setup, hosts that already run VDSM.
Meaning that maybe instead of the FQDN we can just use hostname - so the UUID will be
registered in the tables
I don't why it's so complex, if a host provided is removed from the system
you either get a canDoAction to remove it from the configuration as well (or a warning
that this will remove the host from the fencing configuration). Your only risk if all of
them are removed, then you need to set the exclamation mark again (power management is not
configured for this host)
because this was a text field, and i don't like code having to know to
check some obscure field and parse it for dependencies.
relations between entities are supposed to be via db referential
integrity if possible (we had some locking issues with these).
i prefer implementation will start with the more simple use case not
covering these complexities.
- 5. Thinking about it more, Though the chain is more generic and
flexible, I would like to return to my original suggestion, of having just primary and
secondary proxy:
Primary Proxy 1 => Drop down -> Any cluster host / Any DC host / RHEV Manager
/ Named host out of the list of all the hosts
Secondary Proxy 2 => Drop down -> Any cluster host / Any DC host / RHEV
Manager / Named host out of the list of all the hosts
I think is simpler as far as a user is concerned and it's simpler for us to
implement two fields single value in each. And I don't believe we really need more,
even in the simple case of cluster only hosts, for clusters larger then 4 hosts by the
time you get to the secondary it may be too late. Secondary is more critical for the
'Named host' option or small clusters.
this is a bit simpler. but as for specifying a specific host:
- now you are asking to check two fields (proxy1, proxy2)
- probably to also alert if all these hosts moved to maint, or when
moving them to another cluster, etc.
- it doesn't cover the use case of splitting between switches, sub
clusters, etc. as you are limited to two hosts, which may have been
moved to maint/shutdown for power saving, etc. (since you are using a
static host assignment, rather than an implied group of hosts (cluster,
dc, engine)
3:22 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Simon Grinberg" <simon(a)redhat.com>
Cc: "Eli Mesika" <emesika(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Sunday, November 11, 2012 10:52:53 PM
Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for
Power Management operations
On 11/11/2012 05:45 PM, Simon Grinberg wrote:
> 3. The directly selected hosts comes to accommodate two use cases:
> -3.1- Switch failure - if the fence network for hosts in a
> DC/Cluster have to split between two switches. Then you will
> prefer to use hosts that are for sure on the other switch
> -3.2- Legacy clusters merged into larger clusters due to a move
> to oVirt then the infrastructural may still fit to the legacy
> connectivity - lot's of firewalls rules or direct connections
> that limit access to fencing devices to specific hosts.
> -3.3- Clustered applications within the VMs, you only want your
> peers to be allowed to fence you. This is limited for VMs
> running on specific host group (affinity management that we
> don't have yet, but we can lock VMs to specific hosts).
that's VMs asking to fence (stop) other VMs, not hosts. why are you
mixing it with host fencing?
What happens if the host on which the peer VM is down?
You need to fence the host. I was thinking about preventing a race where the VM asks to
fence it's peer while the engine fences the host. In this case the fence of the peer
VM may be reported as failed (no option to send stop to the VM) while the host status is
yet unknown, or worse may succeed after the host rebooted killing the VM again after it
restarted.
To prevent that you request to fence the host instead of fencing the VM a. But you are
right that it does not matter which host will do the fencing, I was thinking on the old
stile infra.
>
> Note that the above was not meant to accommodate any random
> server, just hosts in the setup, hosts that already run VDSM.
> Meaning that maybe instead of the FQDN we can just use hostname
> - so the UUID will be registered in the tables
> I don't why it's so complex, if a host provided is removed from
> the system you either get a canDoAction to remove it from the
> configuration as well (or a warning that this will remove the
> host from the fencing configuration). Your only risk if all of
> them are removed, then you need to set the exclamation mark
> again (power management is not configured for this host)
because this was a text field, and i don't like code having to know
to
check some obscure field and parse it for dependencies.
relations between entities are supposed to be via db referential
integrity if possible (we had some locking issues with these).
i prefer implementation will start with the more simple use case not
covering these complexities.
> - 5. Thinking about it more, Though the chain is more generic and
> flexible, I would like to return to my original suggestion, of
> having just primary and secondary proxy:
> Primary Proxy 1 => Drop down -> Any cluster host / Any DC
> host / RHEV Manager / Named host out of the list of all the
> hosts
> Secondary Proxy 2 => Drop down -> Any cluster host / Any DC
> host / RHEV Manager / Named host out of the list of all the
> hosts
> I think is simpler as far as a user is concerned and it's
> simpler for us to implement two fields single value in each.
> And I don't believe we really need more, even in the simple
> case of cluster only hosts, for clusters larger then 4 hosts
> by the time you get to the secondary it may be too late.
> Secondary is more critical for the 'Named host' option or
> small clusters.
this is a bit simpler. but as for specifying a specific host:
- now you are asking to check two fields (proxy1, proxy2)
- probably to also alert if all these hosts moved to maint, or when
moving them to another cluster, etc.
- it doesn't cover the use case of splitting between switches, sub
clusters, etc. as you are limited to two hosts, which may have been
moved to maint/shutdown for power saving, etc. (since you are using a
static host assignment, rather than an implied group of hosts
(cluster,
dc, engine)
Are you offering to allow defining hosts-groups? :). I'll be happy if you do, we
really need that for some cases of the affinity feature. Especially those involving
multi-site.
Hosts group == "A set of named hosts within the same cluster"
3:40 a.m.
----- Original Message -----
From: "Simon Grinberg" <simon(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "Eli Mesika" <emesika(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Sunday, November 11, 2012 11:22:29 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: "Simon Grinberg" <simon(a)redhat.com>
> Cc: "Eli Mesika" <emesika(a)redhat.com>, "engine-devel"
> <engine-devel(a)ovirt.org>
> Sent: Sunday, November 11, 2012 10:52:53 PM
> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy
> selection algorithm for Power Management operations
>
> On 11/11/2012 05:45 PM, Simon Grinberg wrote:
> > 3. The directly selected hosts comes to accommodate two use
> > cases:
> > -3.1- Switch failure - if the fence network for hosts in a
> > DC/Cluster have to split between two switches. Then you will
> > prefer to use hosts that are for sure on the other switch
> > -3.2- Legacy clusters merged into larger clusters due to a
> > move
> > to oVirt then the infrastructural may still fit to the legacy
> > connectivity - lot's of firewalls rules or direct connections
> > that limit access to fencing devices to specific hosts.
> > -3.3- Clustered applications within the VMs, you only want
> > your
> > peers to be allowed to fence you. This is limited for VMs
> > running on specific host group (affinity management that we
> > don't have yet, but we can lock VMs to specific hosts).
>
> that's VMs asking to fence (stop) other VMs, not hosts. why are you
> mixing it with host fencing?
What happens if the host on which the peer VM is down?
You need to fence the host. I was thinking about preventing a race
where the VM asks to fence it's peer while the engine fences the
host. In this case the fence of the peer VM may be reported as
failed (no option to send stop to the VM) while the host status is
yet unknown, or worse may succeed after the host rebooted killing
the VM again after it restarted.
To prevent that you request to fence the host instead of fencing the
VM a. But you are right that it does not matter which host will do
the fencing, I was thinking on the old stile infra.
>
> >
> > Note that the above was not meant to accommodate any random
> > server, just hosts in the setup, hosts that already run VDSM.
> > Meaning that maybe instead of the FQDN we can just use
> > hostname
> > - so the UUID will be registered in the tables
> > I don't why it's so complex, if a host provided is removed
> > from
> > the system you either get a canDoAction to remove it from the
> > configuration as well (or a warning that this will remove the
> > host from the fencing configuration). Your only risk if all
> > of
> > them are removed, then you need to set the exclamation mark
> > again (power management is not configured for this host)
>
> because this was a text field, and i don't like code having to know
> to
> check some obscure field and parse it for dependencies.
> relations between entities are supposed to be via db referential
> integrity if possible (we had some locking issues with these).
> i prefer implementation will start with the more simple use case
> not
> covering these complexities.
>
>
> > - 5. Thinking about it more, Though the chain is more generic and
> > flexible, I would like to return to my original suggestion, of
> > having just primary and secondary proxy:
> > Primary Proxy 1 => Drop down -> Any cluster host / Any DC
> > host / RHEV Manager / Named host out of the list of all the
> > hosts
> > Secondary Proxy 2 => Drop down -> Any cluster host / Any DC
> > host / RHEV Manager / Named host out of the list of all the
> > hosts
> > I think is simpler as far as a user is concerned and it's
> > simpler for us to implement two fields single value in
> > each.
> > And I don't believe we really need more, even in the simple
> > case of cluster only hosts, for clusters larger then 4
> > hosts
> > by the time you get to the secondary it may be too late.
> > Secondary is more critical for the 'Named host' option or
> > small clusters.
>
> this is a bit simpler. but as for specifying a specific host:
> - now you are asking to check two fields (proxy1, proxy2)
> - probably to also alert if all these hosts moved to maint, or when
> moving them to another cluster, etc.
> - it doesn't cover the use case of splitting between switches, sub
> clusters, etc. as you are limited to two hosts, which may have been
> moved to maint/shutdown for power saving, etc. (since you are using
> a
> static host assignment, rather than an implied group of hosts
> (cluster,
> dc, engine)
Are you offering to allow defining hosts-groups? :). I'll be happy if
you do, we really need that for some cases of the affinity feature.
Especially those involving multi-site.
Hosts group == "A set of named hosts within the same cluster"
Reading again, I actually like it better then using specific host, it may be worth while
to wait while making sure that when we implement this for SLA we design the hosts grouping
generic enough to be used by the fencing mechanism.
>
>
>
3:47 a.m.
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...
4:01 a.m.
----- 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'
*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.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:21 a.m.
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'
*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.
4:29 a.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'
>
> *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.
Indeed
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:37 a.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
9:33 a.m.
----- 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
Hmm, in this case, maybe we should invoke the script as process from JVM (ugly, but
ScriptEngine, or Eli's suggestion will not work
unless we know the type of the script).
$ file `which fence_ipmilan `
/usr/sbin/fence_ipmilan: ELF 64-bit LSB executable...
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:27 a.m.
On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
----- 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
Saggi has had a nascent attempt to factor the little logic we have out
http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
AFAIR there's nothing there beyond:
- log everything but passwords,
- build the input stream,
- run the script
- convert its return code
and there's also killing dormant scripts on vdsm exist (which I find not
important at all).
Dan.
5:44 a.m.
On 11/11/2012 01:27 PM, Dan Kenigsberg wrote:
On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
>
>
> ----- 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
Saggi has had a nascent attempt to factor the little logic we have out
http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
AFAIR there's nothing there beyond:
- log everything but passwords,
- build the input stream,
- run the script
- convert its return code
and there's also killing dormant scripts on vdsm exist (which I find not
important at all).
if the wrapping isn't doing anything but calling the scripts, then doing
it again from java isn't an issue.
it's only an issue if there is any business logic in the wrapping.
6:47 a.m.
On Sun, Nov 11, 2012 at 01:44:50PM +0200, Itamar Heim wrote:
On 11/11/2012 01:27 PM, Dan Kenigsberg wrote:
>On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
>>
>>
>>----- 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
>
>Saggi has had a nascent attempt to factor the little logic we have out
>http://gerrit.ovirt.org/#/c/7190/7/vdsm/API.py
>AFAIR there's nothing there beyond:
>- log everything but passwords,
>- build the input stream,
>- run the script
>- convert its return code
>and there's also killing dormant scripts on vdsm exist (which I find not
>important at all).
if the wrapping isn't doing anything but calling the scripts, then
doing it again from java isn't an issue.
it's only an issue if there is any business logic in the wrapping.
I believe there's no issue. The only so-called-reason for this verb
existing in Vdsm is the pre-historical platform of oVirt-Engine's
predecessor, which did not support[*] running the fence-agent scripts.
That's why I'm advocating to cut the middle man (even though he is I).
[*] "no support" meaning: "possible, but no one's gonna help you if
there's trouble."
4182
days inactive
4187
days old
26 comments
5 participants
participants (5)
-
Dan Kenigsberg -
Eli Mesika -
Itamar Heim -
Simon Grinberg -
Yair Zaslavsky