From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio M. Di Nitto Date: Mon, 21 Mar 2011 11:44:56 +0100 Subject: [Cluster-devel] RFC: generic improvement to fence agents api In-Reply-To: <4D870F14.8060209@redhat.com> References: <4D844E8F.1050608@redhat.com> <4D870F14.8060209@redhat.com> Message-ID: <4D872C28.9060706@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 3/21/2011 9:40 AM, Marek Grac wrote: > Hi, > > On 03/19/2011 07:34 AM, Fabio M. Di Nitto wrote: >> >> .... >> >> Either by using a new keyword "ports" or re-using "port" itself. If >> using "port", current configuration will continue to work as-is and the >> change effectively would not introduce any backward compatibility issue. >> >> This way the agent can: >> >> 1) connect once (reducing in most cases the ssh/telnet/whatever time) >> 2) issue the OFF command as fast as possible (almost in parallel) >> 3) then wait for the results. >> >> By adopting a list, the configuration would look cleaner too IMHO. >> >> A quick glance, the change should not affect fenced (David can you >> confirm please?), and most agents could handle it via the fencing python >> lib (Marek?). > > 1) connect once will work only for connection-based fence agents. It > won't help with SNMP + HTTP REST and there won't be any benefits for > drac/ilo/ipmi that can turn off only one machine. Rough estimate is that > it can help us to improve time in 1/3 to 1/2 fence agents. Of course, it?s a benefit for a subset of the agents. > > 2) parallelism is possible only on those fence devices that works in > async mode. Issuing more than one command will also increase a need for > QE. Some of those devices are not able even to handle 'get status' > immediately after 'power off' (reason for --power-wait). Serialization > within same connection is definitely possible and for fencing python lib > we can implement that directly in library. Assuming we agree to do it, let?s get it upstream first, then we will worry about QE at a later stage. I think starting from serialization within the same connection is already a good start. The parallelism is not real anyway. I don?t expect forking of commands as that would lead to other issues, as you already described. > > -) "ports" is better than "port" because such change will have impact > also on UI and we have to distinguish if fence agent accept more than > one port or not. ACK. > > -) There is no character that can't be used for name of virtual machine. I don?t think vms are a problem here, since each vm has only one port? Fabio