Alvaro Cornejo schrieb: > > I strongly agree with the intention of this patch; however, we need to > think in some way to have kannel reconnect the smsc-at later on. As > stated, this kind of issues are temporary so the modem/service will be > re-established later on and most of people wouldn't have an active > monitoring system that will alert people that the smsc was shutdown > and take necessary actions to reenable the smsc.
Hi Alvaro, thanks for the positive appeal. In fact I disagree here slightly. Keep in mind that we take he system architecture issue pretty serious with Kannel. Kannel is the "transport layer", providing hooks for the monitoring and flow control logic entity, but not providing the full framework for this on it's own. There are several reasons we didn't want to have it "around" the transportation core. So, if a SIM burns, we shutdown the smsc group, and inform the outside word via the 'dead' status on the HTTP admin status overview. I.e. the XML source can be hooked into monitoring components (Nagios?). Therefore we transfer the responsibility to taken action to the user. The SIM is exchanged, and the admin can restart the specific smsc via the HTTP admin command (URI /start-smsc). > In my system we have 14 modems in addition to other smpp/http smsc's > and have this kind of problems from time to time. So -even If I have > no valid vote- I'm +1 but will prefer it to have it in a way that > kannel autoreconnect/retry to start the smsc after some period of > time. thanks for your vote. You DO HAVE a vote, anyone has, if the reasoning is given and consistent. (the only thing you don't have formally is a veto right ;) Hmmm... as mentioned above, I disagree here for the automatic re-starting of the smsc grouop. Why? Reason: this assumes that Kannel has to assume that someones does take action in the meantime. We can's assume that this way. The heuristic we use ends up in a state where our heuristic has proven, the SIM is dead, so we exclude it from the viable list of smsc routes. >From a system architecture point of view. Kannel can't known more on it's own. It's the action point of an external entity (admin) to take action, and "inform" Kannel that the smsc group is again in operational mode, hence re-starting the smsc group. If you still need this as an automatic approach, you CAN set Nagios triggers to call the HTTP admin command to restart the smsc. Right? ;) But leave this decission to the external entity, rather to assume internally things you can't rely on, (the fact that the SIM has been exchanged). > Also, what about having a different status for the smsc? If it is > "dead" we will not be able to know if it was manually shutdown or by > this patch. It can be something like "disabled"???. Hmmm, this means introducing a new semantical state. I'm +0 here, any other opinions from the group here? Stipe -- ------------------------------------------------------------------- Kölner Landstrasse 419 40589 Düsseldorf, NRW, Germany tolj.org system architecture Kannel Software Foundation (KSF) http://www.tolj.org/ http://www.kannel.org/ mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org -------------------------------------------------------------------
