On Mon, 2009-10-05 at 11:42 -0400, Huijun Yang wrote: > > Hello, > > http://track.sipfoundry.org/browse/XX-6655: 'registrar-config' file > must be replicated when 'Instant Messaging' bundle is added/removed > > Not only "registrar-config" that has settings related to > OpenFire(Instant Messing bundle), there are several other services' > configurations also require settings from OpenFire(Instant Messing > bundle). I think it is rather a generic issue, that is when a bundle > is added/removed, all the configuration files that have reference to > the changed bundle need to be replicated, but let's user > Openfire(Instant Messing bundle) as an example to illustrate the > issue. > > When OpenFire(Instant Messing bundle) is installed, I can understand > that it is necessary that configurations of the services that have > dependence on OpenFire(Instant Messing bundle) need to be replicated, > and related services might need to be restarted in order to get the > changes to take effect. > > However, in the case when 'Instant Messaging' bundle is removed, it is > theoretically logical that the settings related to "Instant Messaging" > bundle should be cleaned from the configuration files that still have > reference to Openfire/InstantMessaging's settings, and restarted > affected services, and make the configuration file LOOK clean. > However, I am not sure from functional point of view, what it really > gains by this cleaning up, and it even causes maybe unnecessary > services restart.. I think there is no harm to have some leftover in > the configurations when a bundle is not available. I am proposing when > a bundle is uninstalled, we don't clean up its settings that > referenced by other services. Anybody see problem with this?
I think that produces inconsistent results (what you get depends on what order you do things in), and that's a Bad Thing. We have not previously spent much effort on being able to change things based on installing/uninstalling. The assumption has been that all services are installed on all systems, and that services are either enabled or disabled (via the appropriate Role) and configurations generated and replicated accordingly. I see no reason to change this (and several reasons not to). _______________________________________________ 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/
