On 05/06/2011 01:35 PM, Mircea Carasel wrote:
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
enforceRole and replicateLocation do different things. We need to make
sure that calling both is redundant.
The replication duplication is caused by the fact that in
ServiceConfiguratorImpl the eager version of SipxReplicationContext is
injected. We need to make sure there was a good reason for that. Anyway,
for send profiles and first run task definitely the lazy version should
be used. This would prevent replication duplication.
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
Dial plans not being replicated is a bug I introduced with fix for XX-9524
However, making dial plans files part of service config is a pretty big
task, i believe, and I think we can live with it the way it is for now.
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
Well, Mongo replication is part of location initialization. Mongo db is
only "regenerated" on master. On slave a sync command is issued. That is
why I chose to put mongo regeneration in initLocation and resync command
in replicateLocation. But, of course, I'm open to suggestions.
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)
I agree with the suggestions, I would add:
6. Use LazySipxReplicationContext for send profiles and first run task
operations
Mircea
_____________________________
My comments inline,
Cristi
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
