On Fri, 2009-09-18 at 12:17 -0400, Damian Krzeminski wrote: > This is a reminder for developers adding new services to sipXecs. > > Since 4.0 release your service can run on any server in the cluster. You > should not make any assumptions about configuration files that belong to > other services. There are very few configuration files that are replicated > everywhere. Most will only get to the server that requires them (it's not > just an optimization - sipxsupervisor will not accept a config file if no > service claims it in the descriptor) > > In reality we are severely restricting this flexibility. Administrators > configure cluster by assigning bundles of services (a.k.a. roles) to a > server. That simplifies configuration of the cluster and it limits the > number of variants that need to be tested. > > However roles/bundles should not be used as an excuse to code in > assumptions about other services location. It's always good to conduct a > mental experiment: "what happens if my service running on its own dedicated > server". Specifically if you need information about some other services or > ports, add it to your service config file. Do not try to parse other > services data.
There is one alternative to the above, and we should be using it a little more than we are - if the configuration item is relevant to anything (or many things) in the domain, then that item should go in the domain-config, and your service should expect to find it there. The domain-config is replicated to all systems in the cluster. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
