From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio M. Di Nitto Date: Sat, 28 Jun 2008 07:01:15 +0200 (CEST) Subject: [Cluster-devel] [RFC] Common cluster connection handler API In-Reply-To: <20080627192726.GF19105@redhat.com> References: <20080627163538.GC19105@redhat.com> <20080627192726.GF19105@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 27 Jun 2008, David Teigland wrote: > On Fri, Jun 27, 2008 at 08:19:36PM +0200, Fabio M. Di Nitto wrote: >>> I was actually hoping that with no more ccsd there'd be no more >>> "connecting" to ccs, but that's probably a topic for one of the ccs >>> meetings... >> >> The only partial advantage you have, as i documented and wrote to >> cluster-devel, is that if you are connected to cman and cman_is_active, >> you are guaranteed 99.9% to connected to ccs without problems (only >> reason for rejection would be lack of resources on the machine, but at >> that point you have more serious issues to worry about). > > Oops, sorry, I'm still not thinking straight about the new ccs... yeah, > that makes sense that if cman is up then ccs should be there, since both > are openais extensions. I'm curious, after cman_init() succeeds, what > more does cman_is_active() mean? In practice would cman_init() ever be > ok, but cman_is_active() not be ok? > Sorry I forgot to mention another important bit. There is also the cman_is_quorated bit that I mentioned in the first email. Some daemons need quorum to be of any use and they often rely on the old ccs_connect behaviour. They should instead rely on cman_is_quorate etc. Fabio -- I'm going to make him an offer he can't refuse.