Add if not exists constraint to create table on upgrade paths

[nvazquez]

Description

Simply add 'IF NOT EXISTS' constraint to 'CREATE TABLE' SQLs on upgrade paths. This avoids upgrade paths to fail if there had been previous failures on the upgrade process.

Fixes: #3891

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):

How Has This Been Tested?

[borisstoyanov]

@blueoranguran package

[borisstoyanov]

@blueorangutan package

[blueorangutan]

@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✖centos6 ✔centos7 ✔debian. JID-883

[yadvr]

@blueorangutan test

[blueorangutan]

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[yadvr]

LGTM, did not check it thoroughly - the changes in the schema-2xx are unnecessary.

[blueorangutan]

Trillian test result (tid-1029)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 28249 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3892-t1029-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermittent failure detected: /marvin/tests/smoke/test_templates.py
Smoke tests completed. 78 look OK, 1 have error(s)
Only failed tests results shown below:

Test	Result	Time (s)	Test File
test_02_vpc_privategw_static_routes	Failure	172.72	test_privategw_acl.py
test_03_vpc_privategw_restart_vpc_cleanup	Failure	166.77	test_privategw_acl.py
test_04_rvpc_privategw_static_routes	Failure	229.75	test_privategw_acl.py

[andrijapanicsb]

wow.... what, why?

-1

If there was previous failure on upgrade, bunch of other things will fail, like extending the existing table or such. I saw the issue which this PR is supposed to fix, and I vote for closing both.

The correct action is failed upgrade --> roll back DB --> start again.

[andrijapanicsb]

To further explain myself - if you attempt the upgrade on top of DB which previously failed to be upgraded, you might end up with duplicate entries trying to be inserted and that would be chaos.
The only "normal" way (acceptable in production) to proceed with the failed upgrade, is to start clean (drop DB, restore DB) and try again.

[DaanHoogland]

@andrijapanicsb I almost agree with you. There is a possibility that two upgrade paths produce conflicting table definitions. In those cases (and in principle) the "CREATE IF NOT EXISTS" pattern is very good to hav as a standard. Double entries are a whole different issue.