----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Simon Grinberg" <si...@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" <dan...@redhat.com> > >> To: "Eli Mesika" <emes...@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" <emes...@redhat.com> > >>>> To: "Itamar Heim" <ih...@redhat.com> > >>>> Cc: "engine-devel" <engine-devel@ovirt.org> > >>>> Sent: Friday, November 9, 2012 12:06:05 PM > >>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving proxy > >>>> selection algorithm for Power Management operations > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Itamar Heim" <ih...@redhat.com> > >>>>> To: "Eli Mesika" <emes...@redhat.com> > >>>>> Cc: "engine-devel" <engine-devel@ovirt.org>, "Michael > >>>>> Pasternak" > >>>>> <mpast...@redhat.com>, "Simon Grinberg" > >>>>> <sgrin...@redhat.com>, "Dan Kenigsberg" <dan...@redhat.com> > >>>>> Sent: Friday, November 9, 2012 12:02:37 PM > >>>>> Subject: Re: [Engine-devel] [Design for 3.2 RFE] Improving > >>>>> proxy > >>>>> selection algorithm for Power Management operations > >>>>> > >>>>> On 11/09/2012 10:52 AM, Eli Mesika wrote: > >>>>> > >>>>>>>> > >>>>>>>> > FenceWrapper > >>>>>>>> > >>>>>>>> i understand danken suggested going this way, rather than > >>>>>>>> than > >>>>>>>> another > >>>>>>>> instance of vdsm. > >>>>>>>> is vdsm only calling these scripts today and all logic is > >>>>>>>> in > >>>>>>>> engine, > >>>>>>>> or > >>>>>>>> does vdsm has any logic in wrapping these scripts (not a > >>>>>>>> blocker > >>>>>>>> to > >>>>>>>> doing FenceWrapper, just worth extracting that logic from > >>>>>>>> vdsm > >>>>>>>> to > >>>>>>>> such a > >>>>>>>> script, then using it in both. i hope answer is 'no > >>>>>>>> logic'...) > >>>>>> vdsm has some logic that maps between the call passed to it > >>>>>> from > >>>>>> engine and the actual parameters generated for the script. > >>>>>> AFAIK, this logic only "builds" the correct arguments for the > >>>>>> command according to the agent type > >>>>>> > >>>>> > >>>>> can we extract it to an external wrapper? > >>>>> I'd hate to fix bugs/changes twice for this. > >>>> > >>>> I'll check it with danken on SUN > >>> > >>> Well, looked at it a bit , the VDSM code is in fenceNote function > >>> in API.py > >>> What I think is that we can exclude the fenceNote implementation > >>> to > >>> a separate fence.py file and call it from the API.py > >>> Then we can use one of the following in Java to call the method > >>> from fence.py > >>> 1) jython > >>> 2) org.python.util.PythonInterpreter > >>> > >>> See > >>> http://stackoverflow.com/questions/8898765/calling-python-in-java > >>> > >>> 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 > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel