Are you telling me that I have no clue about how the boxes work? Really? This is not worth to be even answered. As usual, arguing with you is a waste of time. -- Alex Guerrieri
On 19/12/2010, at 18:58, Nikos Balkanas <nbalka...@gmail.com> wrote: > Well I have worked with many distributed and clustered systems, and i can > tell you that all use distributed administration. Sun clusters, IBM clusters, > you name it. Of course, since these are commercial products, they do not rely > on an html page, but instead they supply their own external application that > connects to each system and presents a centralized view. This is essential > for operation, since if one node goes down, you can still administer the > other. > > I suggest you look more carefully at the things you are saying. Besides no > one suggested to use wiki for the job. Still you have no clue how to > differentiate between sqlbox, smppbox and smsbox. Good luck with that. > > Nikos > > On Sat, Dec 18, 2010 at 7:47 PM, Alejandro Guerrieri <aguerri...@kannel.org> > wrote: > 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 > aguerri...@kannel.org > > > > 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 <nbalka...@gmail.com> 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 <aguerri...@kannel.org> >> 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 >> aguerri...@kannel.org >> >> >> >> 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 >>> <aguerri...@kannel.org> 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 >>> aguerri...@kannel.org >>> >>> 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 ; devel@kannel.org >>> > 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 <david.a.mcc...@gmail.com> >>> > 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 <nbalka...@gmail.com> >>> > 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 <david.a.mcc...@gmail.com> >>> > 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 >>> > >>> >>> >> >> >> > >
