Scott Lawrence wrote: > On Mon, 2009-11-16 at 13:06 -0500, Damian Krzeminski wrote: >> Scott Lawrence wrote: >> >> [...] >> >>>> I suspect sipXconfig implementation would be simpler if sipXalarms were to >>>> be separated from sipXsupervisor. At the moment we have a special case for >>>> configuring alarms in the sipXconfig code and it has already caused several >>>> issues (recently: http://track.sipfoundry.org/browse/XX-6970). >>>> It's not directly related to adding alarm functionality but it seems we >>>> would be adding even more config files for alarm service, which is trivial >>>> if this is a 'normal' service and complicated if it's a sipXsupervisor. >>> I don't see what the problem is with the above; integrating the alarm >>> monitor into sipXsupervisor. The particular issue you cite seems easy >>> to me - the replication of that file happens through sipXsupervisor >>> anyway; it should be able to notice that fact and reload the definitions >>> without any other prompting. >>> >> It is a problem: sipXsupervisor cannot be started or stopped like other >> services (because it's doing starting and stopping): it needs to be treated >> differently. > > I think that the supervisor function and the alarm monitor function are > similar in that they are both things you never want to stop anyway. > >> sipXsupervisor detecting changes to its config files would not solve >> anything. Part of the problem - uncaught be testing yet - was that >> sipXconfig did not push all the files to a newly added host. > > I don't see how that's relevant to whether or not the alarm monitor > should be a part of the supervisor... if sipXconfig is not pushing all > the config files to a new host that it needs to, that's just a bug, not > a design constraint. Perhaps we're talking about different things? >
I am sorry I cannot explain it better. I believe that the system would be easier to configure, manage and debug if sipXsupervisor concentrated on service management and intra-service communication. For example all other services can just declare that they need particular resources and they won't start without them. That in turn ensures that sipXconfig can push all config files before it starts the service. sipXsupervisor - for obvious reasons - starts even when it misses the config file (alarm config in this case). And when something does not work then, there is no clear indication what went wrong. Because of that it's best if we keep the list of config files for sipXsupervisor, and in consequence a list of functionality provided by sipXsupervisor as short as possible. But this is all of secondary concern to me, so I am letting it go. Damian _______________________________________________ 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/
