On 10 Dec 2013, at 11:31 pm, Brian J. Murrell <[email protected]> wrote:
> On Tue, 2013-12-10 at 10:27 +0000, Christine Caulfield wrote: >> >> Sadly you're not wrong. > > That's what I was afraid of. > >> But it's actually no worse than updating >> corosync.conf manually, > > I think it is... > >> in fact it's pretty much the same thing, > > Not really. Updating corosync.conf on any given node means only having > to write that file on that node. There is no cluster-wide > synchronization needed Approximately speaking, cman takes cluster.conf and generates an in-memory corosync.conf equivalent to be passed to corosync. So anything that could be done by editing corosync.conf should be possible with 'ccs -f ...', neither command results in any synchronisation or automatic update into the running process. > and therefore no last-write-wins race so all > nodes can do that in parallel. Plus adding a new node means only having > to update the corosync.conf on that new node (and starting up corosync > of course) and corosync then does the job of telling it's peers about > the new node rather than having to have the administrator go out and > touch every node to inform them of the new member. It sounds like this thread is less about cluster.conf vs. corosync.conf and more about autodiscovery vs. fixed node lists. Chrissie: is there no way to use cman in autodiscovery mode (ie. with multicast/broadcast and learning about peers as they appear)? > > It's this removal of node auto-discovery and changing it to an operator > task that is really complicating the workflow. Granted, it's not so > much complicating it for a human operator who is naturally only > single-threaded and mostly incapable of inducing the last-write-wins > races. > > But when you are writing tools that now have to take what used to be a > very capable multithreaded task, free of races and shove it down a > single-threaded pipe/queue just to eliminate races, this is a huge step > backwards in evolution. > >> so >> nothing is actually getting worse. > > It is though. See above. > >> All the CIB information is still >> properly replicated. > > Yeah. I understand/understood that. Pacemaker's actual operations go > mostly unchanged. It's the cluster membership process that's gotten > needlessly complicated and regressed in functionality. > >> The main difficulty is in safely replicating information that's needed >> to boot the system. > > Do you literally mean staring the system up? I guess the use-case you > are describing here is booting nodes from a clustered filesystem? But > what if you don't need that complication? This process is being made > more complicated to satisfy only a subset of the use-cases. > >> In general use we've not found it to be a huge problem (though, I'm >> still not keen on it either TBH) because most management is done by one >> person from one node. > > Indeed. As I said above, WRT to single-threaded operators. But when > you are writing a management system on top of all of this, which > naturally wants to be multi-threaded (because scalable systems avoid > bottlenecking through single choke points) and was able to be > multithreaded when it was just corosync.conf, having to choke everything > back down into a single thread just sucks. > >> There is not really any concept of nodes trying to >> "add themselves" to a cluster, it needs to be done by a person - which >> maybe what you're unhappy with. > > Yes, not so much "add themselves" but allowed to be added, in parallel > without fear of racing. > > This ccs tool wouldn't be so bad if it operated more like the CIB where > modifications were replicated automatically and properly locked so that > modifications could be made anywhere on the cluster and all members got > those modifications automatically rather than pushing off the work of > locking, replication and serialization off onto the caller. > > b. > > _______________________________________________ > Pacemaker mailing list: [email protected] > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pacemaker mailing list: [email protected] http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
