Hi Jan! Am 11.04.2013 11:54, schrieb Jan Friesse: > Ulf Wendel napsal(a): >> Am 11.04.2013 10:43, schrieb Jan Friesse: >>> Ulf Wendel napsal(a): >>>> Am 10.04.2013 15:02, schrieb Jan Friesse: >>>>> Ulf Wendel napsal(a): >>>>>> - Can executive daemon be added and removed online? >>>>>> >>>>> >>>>> Sure >>>>> >>>>>> I assume the number of application clients is limited by practical >>>>>> matters only, for example, time required to reach out to all connected >>>>>> application clients shoud be considered. Clients can connect and >>>>>> disconnect without bringing the cluster down. >>>>>> >>>>>> But, what if one wants to add executives? Will this require >>>>>> reconfiguration of all other executives in the cluster, will the cluster >>>>>> go down or experience a view change only... >>>>>> >>>>> >>>>> As long as you are using udp (multicast) nothing is needed. For udpu >>>>> (unicast), you must issue commands described in cmap_keys man page. >>>> >>>> >>>> Excellent! >>>> >>>> I've had only a quick look at spread.org but it seemed to me that >>>> spread.org required updating and deploying the config file manually. As >>>> I understand you, config deployment is an integral part of the corosync >>>> API and can be done at runtime. >>> >>> Actually it's only partly true. You still need to deploy configuration >>> file (config deployment is for sure one of things which may be so nice >>> to have and there were ideas of using DNS for that), but when using >>> multicast, you can set mcast bind address to network address (so let's >>> say network is 192.168.1.0/24 and n1 is 192.168.1.1, n2 is 192.168.1.2, >>> ..., you can set 192.168.1.0 as bindaddr in corosync.conf) and don't >>> need to configure each node in file on each node (as in spread toolkit). >> >> >> I see: given a private network and the ability to use UDP multicast, >> plain multicast may do the trick. Luckily, that works for me. Good to >> learn about spread toolkit offering a similar feature set. I wasn't sure >> after reading their manuals. >> > > ... I don't know if spread really offers similar feature set. What I've > told is, that corosync can use multicast and it's not necessarily needed > to add every node in config file on each node (this is needed in spread). > >> Yes, manual config deployment is kind of a limitation. However, there > > Actually, take a look to pcs (https://github.com/feist/pcs). This may > save a quite a lot work for you (I didn't tried it yet). Nice hint and its fantastic to hear such piece exist. But I'll most likely never use any of them. Learning it could be done is all need at this point. >> seem to be very few free and open source solutions available. If you put >> a C/C++ constraint on top, the number is even further reduced. >> > > Ya. Actually, as far as I know, Corosync is really only one actively > developed + maintained with really open source license (spread License > is more like original 4-Clause BSD license so not free) group messaging > system with C API. A plain static open source GCS library would do the trick for me. There's libPaxos but its intentionally distributed under the terms of GPLv3. GPLv3 has been choosen to hinder production use - it is not meant to be production quality. And there's little of the vodoo and convenience in libPaxos that Corosync has to offer. Thanks, Ulf _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
