From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Grac Date: Mon, 21 Mar 2011 09:40:52 +0100 Subject: [Cluster-devel] RFC: generic improvement to fence agents api In-Reply-To: <4D844E8F.1050608@redhat.com> References: <4D844E8F.1050608@redhat.com> Message-ID: <4D870F14.8060209@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. 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. -) "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. -) There is no character that can't be used for name of virtual machine. m,