On Wed, 2008-09-24 at 18:22 +0300, Bogdan Brezoi wrote: > Hi all, > > I would like to summarize what we discussed with Kevin and Scott about > the configuration stamp for sipx services ( > http://track.sipfoundry.org/browse/XCF-2612 ).
Thanks for posting Bogdan, I just had a couple quick comments... > SipXsupervisor needs the configuration stamp value in order to compare > it to the actual service version. If they are both the same, the service > can be started. Otherwise the state of the service will be set to > "ConfigurationVersionMismatch". > SipXconfig should be responsible for sending the configuration stamp > value via XML-RPC layer to SipXsupervisor. This should happen whenever > the configuration for a specific service changes (and gets replicated) > or when a new service is added for a specific host. As far as we now, > the configuration of a service can get changed at application's startup > or from the System/Server/Services page (as per user action). > In conclusion the stamp will be passed to sipXsupervisor in the above > use cases. If I understood the conversation on #sipx correctly, this stamp only needs to be sent once for a specific version. Since the version isn't going change at runtime (this may change in the future if we were to support running services of versions different than sipXconfig) we only need to send the version stamp once per service per sipXconfig application session. However it does not hurt to send it more than once. Also note that the stamp only should (should is binding here) be sent when all the configuration files for a given service are replicated. Currently, we associate one configuration object to each service. This is going to need to be changed in order to accommodate services that have more than one config file. Then we will need to send the version stamp once all files have been replicated. I had originally envisioned the version stamp being sent in the replication code, but due to this fact I think we are going to need to provide a call that the service can invoke once all its files have been replicated. Of course, there may be a better way. Kevin _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
