[Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
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
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
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Dan Kenigsberg" <danken@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
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'...)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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
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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/11/2012 01:18 PM, Eli Mesika wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 01:18 PM, Eli Mesika wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/11/2012 02:27 PM, Yair Zaslavsky wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 01:18 PM, Eli Mesika wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Eli Mesika" <emesika@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, November 11, 2012 1:45:53 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/11/2012 01:18 PM, Eli Mesika wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Sent: Friday, November 9, 2012 12:02:37 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
On 11/09/2012 10:52 AM, Eli Mesika wrote:
>>> >>> > FenceWrapper >>> >>> i understand danken suggested going this way, rather than >>> than >>> another >>> instance of vdsm. >>> is vdsm only calling these scripts today and all logic is in >>> engine, >>> or >>> does vdsm has any logic in wrapping these scripts (not a >>> blocker >>> to >>> doing FenceWrapper, just worth extracting that logic from >>> vdsm >>> to >>> such a >>> script, then using it in both. i hope answer is 'no >>> logic'...) > vdsm has some logic that maps between the call passed to it > from > engine and the actual parameters generated for the script. > AFAIK, this logic only "builds" the correct arguments for the > command according to the agent type >
can we extract it to an external wrapper? I'd hate to fix bugs/changes twice for this.
I'll check it with danken on SUN
Well, looked at it a bit , the VDSM code is in fenceNote function in API.py What I think is that we can exclude the fenceNote implementation to a separate fence.py file and call it from the API.py Then we can use one of the following in Java to call the method from fence.py 1) jython 2) org.python.util.PythonInterpreter
See http://stackoverflow.com/questions/8898765/calling-python-in-java
if this is JNI, i think it won't fly for engine. JNA may be viable. or just shell launch
Can you elaborate here on JNI vs JNA? (besides of course the risks of invoking JNI code from JEE code)? Am I missing something else here?
you are not missing, it's about JNI from JEE
Hmm... now that I remember our previous JNA adventure , and after looking at some resources, I'm staring to think whether JNA code is really safer (not talking about the ease of development here). I started digging at JNA code -and JNA is actually JNI (i.e - uses native methods) based framework (infra to ease native code development) - So one can say it relies on the fact this is open source and used by various comments, but at the end - this is still JNI behind the scene (see jna/src/com/sun/jna/Native.java) Bugs still can occur at JNA code (maybe less, as it's supposed to be "cleaner" code) - but if there are bugs, JVM crashes.
danken, what do you think ?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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-scr... 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Simon Grinberg" <simon@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Dan Kenigsberg" <danken@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@redhat.com> To: "Dan Kenigsberg" <danken@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@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"
----- Original Message -----
From: "Simon Grinberg" <simon@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, "engine-devel" <engine-devel@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.
On Sun, Nov 11, 2012 at 06:18:53AM -0500, Eli Mesika wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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...
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/12/2012 12:01 PM, Simon Grinberg wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Friday, November 9, 2012 12:06:05 PM Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy selection algorithm for Power Management operations
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Fri, Nov 09, 2012 at 05:06:05AM -0500, Eli Mesika wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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.
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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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.
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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak" <mpastern@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Dan Kenigsberg" <danken@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."
participants (5)
-
Dan Kenigsberg -
Eli Mesika -
Itamar Heim -
Simon Grinberg -
Yair Zaslavsky