Re: Submitting a patch to Kannel: best practices?

Sure, go maintain it yourself manually on a set of thousands of nodes.

The easiest thing is to let the _system_ keep track of its registered resources and provide you with that list.

Go check how most clustered systems work, I bet you won't find many requiring the administrator to create a wiki page with the urls.
--
Alejandro Guerrieri
[email protected]



On 18/12/2010, at 18:40, Nikos Balkanas wrote:

> Besides, in a distributed administration system, the easiest thing is to have a custom page with links to each system, therefore, so that everything is managed from a centralized URL.
> 
> BR,
> Nikos
> 
> On Sat, Dec 18, 2010 at 7:34 PM, Nikos Balkanas <[email protected]> wrote:
> No, it won't. smsbox-admin-id is no better than smsbox-id for this purpose. In terms of software it doesn't tell anything more to bb, to differentiate sqlbox from smppbox or a regular smsbox connection, so that it can show different configuration options for each one.
> 
> I have also adequate experience with clusters, farms and distributed computing. Kannel will have to rewrite major portions of its interface to be used in such.
> 
> I think that we have just about exhausted this topic.
> 
> BR,
> Nikos
> 
> On Sat, Dec 18, 2010 at 4:02 PM, Alejandro Guerrieri <[email protected]> wrote:
> An approach similar to the one we use with the smsc-admin-id would work perfectly.
> 
> smsbox-id, for routing.
> smsbox-admin-id for sending commands.
> 
>> A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios.
> 
> I disagree with that, as most of the industry does. Clusters are managed from a central place, not from each box alone (and I have my share of experience with clusters to back my point). Might work for 2-3 boxes, but try to manage 10 instances by hitting 10 different urls on 10 different servers. Scale that to 100, 1000, 10000...
> 
> Regards,
> --
> Alejandro Guerrieri
> [email protected]
> 
> 
> 
> On 18/12/2010, at 14:48, Nikos Balkanas wrote:
> 
>> I don't think that wholistic centralized management is an acceptable option. Even with centralized management smsbox-id will be required. There are several features that are only applicable to the particular instance you need them. For example, live reconfiguration of services or sendsms accounts to a particular smsbox. It is not available yet, but there is no benefit in excluding it from a future version. As far as the other smsbox types go (sqlbox, smppbox), they should be allowed to have their own sets of live parameters, completely different than standard smsbox, according to their needs without trapping them to an "smsbox format". These "extra features" or lack thereof cannot be distinguished by smsbox-id alone.
>> 
>> A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios.
>> 
>> BR,
>> Nikos
>> 
>> On Fri, Dec 17, 2010 at 8:50 PM, Alejandro Guerrieri <[email protected]> wrote:
>> Well, it's a tradeoff, as usual.
>> 
>> If you get a complex cluster of services, usually you either manage them altogether (and lose granularity), or manage them individually (and each time you need to change something on all of them you need to do it X times).
>> 
>> Now, a good compromise would be to be able to optionally target a specific instance by passing the smsbox-id. If you don't pass it, the command is delivered to all the connected smsboxes, but if you pass it the command is only passed to that specific smsbox instance.
>> 
>> Regards,
>> --
>> Alejandro Guerrieri
>> [email protected]
>> 
>> On 17/12/2010, at 19:44, Nikos Balkanas wrote:
>> 
>> > Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might want to be able to change dynamically log levels to each one, or dynamically manage sendsms accounts. You will end up with a bb admin page a mile long. Besides, sqlbox has different admin requirements than smppbox or smsbox and bb cannot tell them apart.
>> >
>> > BR,
>> > Nikos
>> > ----- Original Message ----- From: Alexander Malysh
>> > To: Nikos Balkanas
>> > Cc: David McCann ; [email protected]
>> > Sent: Friday, December 17, 2010 5:04 PM
>> > Subject: Re: Submitting a patch to Kannel: best practices?
>> >
>> >
>> > Hi,
>> >
>> >
>> > it would be better to let bearerbox tell smsbox to reload lists. admin message already exists for communication
>> > between bearerbox and smsbox (see restart command as example).
>> >
>> >
>> > Then you don't need extra admin interface for smsbox.
>> >
>> >
>> > Thanks,
>> > Alexander Malysh
>> >
>> >
>> > Am 17.12.2010 um 14:49 schrieb Nikos Balkanas:
>> >
>> >
>> > Hi David,
>> >
>> >
>> >
>> > Yes. bb has its own black/white lists for incoming MO traffic, similar to smsbox's MT. These can be reloaded on the fly through its http admin interface. Another very useful feature is that it allows you to change log-levels on the fly. Very useful for debugging.
>> >
>> >
>> > Check gw/bb_http.c: httpd_commands for sources.
>> >
>> >
>> > I am not talking about bearerbox telling smsbox to reload its lists. I am talking for a separate http admin for smsbox, like the one in bb. Otherwise you would have major restructuring to get it through the admin *Msg, and it is not worth it.
>> >
>> >
>> > BR,
>> > Nikos
>> >
>> >
>> > On Fri, Dec 17, 2010 at 1:07 PM, David McCann <[email protected]> wrote:
>> >
>> > Hi Nikos--
>> >
>> >
>> > Thank you for the promt reply!  I completely agree that this makes more sense as a bearerbox, admin command.  I initially added it as such, but then realized that in fact, all the translations logic sat within the smsbox process, rather than the bearerbox.  Adding it directly as an smsbox command removes any need for any communication between the bearerbox and the smsbox.
>> >
>> >
>> > But I agree it still feels like a hack, in terms of where a user would expect to send a command such as "refresh list."  If you could point me to a pattern in the code where the bearerbox communicates with the smsbox in a similar fashion, it'd be a huge help and I'd be happy to re-submit my patch with it working in that manner.  The current diff is still attached to the feature request, but I've attached it here as well (currently in two patches, src and doc) just for review, as we discuss this alternate approach.
>> >
>> >
>> > In regards to your comment about bearerbox handling this on the fly through its admin HTTP interface...I'm not quite sure I follow?  I know this service-level refreshing functionality doesn't currently exist, are you just referring to similar functionality that exists in bearerbox?  Forgive my confusion.
>> >
>> >
>> > Thanks again,
>> > --dm
>> >
>> >
>> >
>> >
>> > On Fri, Dec 17, 2010 at 1:07 PM, Nikos Balkanas <[email protected]> wrote:
>> >
>> > Hi,
>> >
>> >
>> >
>> > Usually people just post the patch to the devel list with subject: Patch: <filename>. Patch is attached as a diff of the file(s) from latest svn sources, followed by a brief description in the body.
>> >
>> >
>> > Wrt to your proposed solution, I am not very much in favor. In bearerbox this is handle on the fly through its admin HTTP interface. I think a similar approach would be best for smsbox.
>> >
>> >
>> > BR,
>> > Nikos
>> >
>> >
>> > On Fri, Dec 17, 2010 at 8:10 AM, David McCann <[email protected]> wrote:
>> >
>> > Greetings all!
>> >
>> >
>> > I've been a kannel user for years, but within the past week I've just started to work directly with the code.  I had a particular need which I couldn't find a good workaround for:
>> >
>> >
>> > My current deployment with kannel uses whitelisting to dispatch messages to various running web applications (at the sms-service group level), however users do update their contact information from time to time, meaning the whitelist needs to updated, preferrably without the smsbox having to be restarted entirely.
>> >
>> >
>> > I've added a new command to the list of available commands for SMSBox, namely /cgi-bin/refreshlist, and (maybe a little overzealously) created an issue: https://redmine.kannel.org/issues/584
>> >
>> >
>> > And submitted my patch there.
>> >
>> >
>> > Given that I'm pretty new to this community, I'm wondering if anyone can advise me on the best/most convenient way to submit a patch for incorporation into the code?
>> >
>> >
>> > Thanks in advance,
>> > David McCann
>> > T4D, UNICEF Uganda
>> >
>> 
>> 
> 
> 
>