As a separate issue for a morning discussion, we need to discuss the varius "*ctl" apps.
The INSTALL document fails to mention that we have kamdbctl that will populate the databases with the proper tables and indexes automagically for you. Now, this is on the kamailio side of our schizophrenic product, so it's propably not very generic - or have we reached a stage where the database tables are the same for both variants of sip-router?
If so, we should propably move kamdbctl out of the kamailio corner, move it up front and rename it srdbctl or something more generic.
When we package Kamailio for release 3, we can modify the INSTALL for that distro, but if we can avoid having to mantain duplicates or different versions of documentation, life will be much easier for everyone involved.
Your thoughts or feedback on this, please!
/O
Olle E. Johansson writes:
If so, we should propably move kamdbctl out of the kamailio corner, move it up front and rename it srdbctl or something more generic.
i support that. i would like to be able to list modules that i use (sr, s and k) and get a script that produces a script that creates the necessary tables.
i have now done it by creating k style db table schemas for those s tables that i need and then included them in kamailio-extensions.xml. for example, i have in kamailio-extensions.xml:
<xi:include href="domain.xml"/> <xi:include href="domain_attrs.xml"/>
if s does not currently have its own schema system and scripts, then why not use the k ones?
-- juha
On Fri, Oct 9, 2009 at 9:02 AM, Olle E. Johansson oej@edvina.net wrote:
As a separate issue for a morning discussion, we need to discuss the varius "*ctl" apps.
The INSTALL document fails to mention that we have kamdbctl that will populate the databases with the proper tables and indexes automagically for you. Now, this is on the kamailio side of our schizophrenic product, so it's propably not very generic - or have we reached a stage where the database tables are the same for both variants of sip-router?
No, not yet, so far we have two separate database schemas.
If so, we should propably move kamdbctl out of the kamailio corner, move it up front and rename it srdbctl or something more generic.
I agree. IMHO both kamctl and kamdbctl tools can be promoted as new management scripts for sip-router.
On ser side we currently have no equivalent of kamctl. We have a bunch of management tools written in python but these tools need to be updated for sip-router. In fact they can live alongside of kamctl, because their purpose is slightly different.
As for kamdbctl, on ser side there are similar script for each database (i.e. ser_mysql.sh, ser_postgres.sh). But they are less advanced than kamdbctl so we can adopt kamctl and remove the ser scripts from the repository later.
Jan.
Jan Janak writes:
I agree. IMHO both kamctl and kamdbctl tools can be promoted as new management scripts for sip-router.
regarding kamctl, i don't think that it is a good idea to include possibility to provision database table entries with it. lcr, for example, has a large number of fields in gw table and it is very cumbersome to try to add gws using kamctl. phpmyadmin, siremis, etc. are much better tools for that.
so my suggestion is to drop all db record related operations from kamctl.
-- juha
On Freitag, 9. Oktober 2009, Juha Heinanen wrote:
I agree. IMHO both kamctl and kamdbctl tools can be promoted as new management scripts for sip-router.
regarding kamctl, i don't think that it is a good idea to include possibility to provision database table entries with it. lcr, for example, has a large number of fields in gw table and it is very cumbersome to try to add gws using kamctl. phpmyadmin, siremis, etc. are much better tools for that.
so my suggestion is to drop all db record related operations from kamctl.
I also think that the scripts are a bit cumbersome, i never used kamctl for DB provisioning sof far. But aparently some people uses this, as i received a bunch of patches for adding support for cr tables for example, or to fix problems in existing ctl code in the past. So i don't think we should remove it right now. Before that we should add a "this is obselete and its planned to be removed, please speak up now" warning message to the script and let it stay there for one release cycle.
Regards,
Henning
-
Henning Westerholt -
Jan Janak -
jh＠tutpro.com -
Olle E. Johansson