----- Original Message ----- > From: "Simon Grinberg" <si...@redhat.com> > To: "Eli Mesika" <emes...@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Dan Kenigsberg" > <dan...@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" <emes...@redhat.com> > > To: "Dan Kenigsberg" <dan...@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" <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 ? > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
