Hi,

We are heavily using Kamailio in our product Sipwise NGCP and currently testing possibility to provide rollback for the customers with the huge systems as the last resort functionality in case if upgrade went wrong. We hope never use it on practice but prefer to have such possibility.

The main logic here is to change DB in 'backward compatible' way. So OLD code must work with NEW DB schema (but NOT a vice verse).

We have some rules which helps us care about it, like "Do not drop columns, just discontinue them" and "All new fields should have defaults", etc.

Also we have separated 'code', 'configs' and 'data' parts of our product and rollback 'code'/'configs' only, while 'data' (e.g. MySQL DB) stays in new state. Otherwise rollback will require a lot if time to revert all DB statements and sometimes it is just not possible.

While every time we have to upgrade Kamailio we have a problems with rollback possibility. The point here that Kamailio checks DB table_version and doesn't start if the version mismatch found.

Q: What about to add Kamailio possibility to work in backward compatible mode?

Sample for upgrade Kamailio 4.3.x -> 4.4.x (the versions here as an example only!) https://www.kamailio.org/wiki/install/upgrade/4.3.x-to-4.4.0 We have 3 DB statements there which are adding new columns to 3 tables, like

-- table: active_watchers ALTER TABLE active_watchers ADD COLUMN flags INT(11) NOT NULL DEFAULT '0', ADD COLUMN user_agent VARCHAR(255) NOT NULL; DELETE FROM version WHERE TABLE_NAME='active_watchers'; INSERT INTO version (`table_name`, `table_version`) VALUES

('active_watchers','12');

Problem here is missed default for column 'user_agent' which can be empty value as for me. So, lets assume we have it there. Then we can add new column to table 'version', like that:

mysql> select * from version where table_name='active_watchers'; +-----------------+---------------+---------------------+ | table_name | table_version | table_compatibility | +-----------------+---------------+---------------------+ | active_watchers | 12 | 11 | +-----------------+---------------+---------------------+ 1 row in set (0.00 sec)

Currently: - module presence version 4.4.x starts check required version and refuse to load if table_version!=12

Proposed behaviour: - module presence version 4.4.x starts check required version and refuse to load if table_version!=12 and compatibility option is not set - if compatibility option is set, check value of table_compatibility and refuse to load if current version less then table_compatibility value

From the sample above I would say module presence in Kamailio 4.4.x is

compatible with Kamailio 4.3.x if we define default value for the field 'user_agent'.

Having that will allow us to rollback on previous NGCP release and _temporary_ work on Kamailio 4.3.x having new Kamailio DB 4.4.x

P.S. This is just a question to check Kamailio community vision here and reality is more complex as described, so some additional checks/limitations will be in place.

P.P.S Compatibility Kamailio option can/should be disabled by default. Field 'table_compatibility' can be outside table 'version', e.g. in separate table. Complete compatibility logic can be some separate Kamailio 'compatibility' module.

Thank you!