> > > > I agree with you, the way it appears to be working doesn't sound very > useful. I'm sure there's no comments explaining why. Does the code > explicitly call out these exceptions, or given the design do you feel > it could be an likely mistake. If you have a few minutes to get to > the bottom of it, it would be greatly appreciated, I certainly have > made assumptions on customer machines that send profiles send all > config info. > I think that the code can be more organized than the way it is now, in this way, duplicate replications can be avoided
I also think that sendProfiles should do exactly the same thing as firstRunTask concerning replications, meaning to replicate all config I made some more analysis and here are my findings: 1. methods that are involved in replications: * initLocation(Location)* -replicates domain-config -replicates supervisor configuration file -replicates alarm server service -generates all data in Mongo *replicateLocation(Location)* -replicates all services config files -re-synch Mongo DB *enforceRole(Location)* -stops all services that are marked to be stopped -launches executor that replicates all services that need to be replicated (services that need to be started, minus the one that are stopped, stopped services don't need to be replicated) *replicateDialPlans()* -replicate dialplans (marked as deprecated, at some point dial-plan conf files should be moved to services) -dial plan has its own replication manager: DialPlanActivationManager *initLocations()** * -iterates through all locations an calls* initLocation(location)* * *-calls *replicateDialPlans()* *enforceRoles()* * *-calls *initLocations()* -iterates through all locations and calls *enforceRole(Location)* * * 2. This is what sendProfiles does for all selected locations *calls *initLocation(location)* * **calls *replicateLocation(location)* *calls *enforceRole(location)* * *- if primary is selected - generate DNS records 3. This is what *runTask *in FirstRunTask does -initializes domain/special users -configures dialplans, paging server, default sbc, alarm server *replicates alarm service *replicates freeswitch service *calls *enforceRoles()* * *-generates gateways, phones profiles All of these, I think can be better organised 1. both enforceRole and replicateLocation deal with service replication. Calling both of them in sendProfiles for sure leads to replication duplication issues that I reported in a different email - this tandem should be redesigned, IMO 2. dial-plan replication is somehow in the air, being treated separately at this moment - dial plan conf files should be made service conf files (as one comment in the code suggests) and remove dialplan replication from initLocations(). initLocations() should call initLocation(location) for every location in the system and nothing more, otherwise is confusing 3. we should not call alarm service replication or freeswitch replication separately in runTask code. this is addressed in enforceRoles anyway 4.looks weird to me why initLocation generates all mongo replication - this should be addressed by replicateLocation. initLocation should deal only with location initialization 5.enforceRole(Location) and enforceRoles() look confusing to me. enforceRoles look more elaborate - since it calls initLocations() My proposal: 1.initLocation should deal only with location initialisation (do not replicate in mongo there) 2.there should be only one method that perform replication operations - that should be replicateLocation 3. replicateLocation should be more flexible, to be able to address partial replication that enforceRole does 4. we should not keep enforceRole/enforceRoles() methods, service stop operations that we need to perform should be addressed in a dedicated method 5. Basically we should have only : initLocation(location), replicateLocation(location), new method: stopStartServices(location) Mircea > _____________________________ __________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
