New subject: [kamailio 5.0] upgrade VS rollback/backward compatibility

12 Apr 2016

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!

-- 
Alexander Lutay
Head of Quality Assurance
Sipwise GmbH, Campus 21/Europaring F15
AT-2345 Brunn am Gebirge

Office: +43(0)13012036
Email: alutay(a)sipwise.com
Website: https://www.sipwise.com

Meet us @ ANGACOM: Hall 10.1 / booth N10
Exhibition and Congress for Broadband,
Cable & Satellite: 07 – 09 June, 2016 in Cologne