...
# | Assumption | Notes |
---|---|---|
1 | There will be separate short and long term solutions | |
2 | ETH wil provide SQL transformation statements (including rollback) with help from CPS Team re. dmi-registry model updates |
Issues & Decisions
# | Issue | Notes | Decision | ||||||
---|---|---|---|---|---|---|---|---|---|
1 | Short term solution will be delivered on 'latest branch | NOT in any specific commit/version mention in original bug | Agreed in meeting with stakeholders on | ||||||
2 | Where to Store Version Number | Database/ Liquibase (Liquibase not possible for NCMP) CPS-Core Liquibase as 'id' field which act as vessio. Current id/version is 15 see changelog/db/changes/15-rename-column-yang-resource-table.yaml | |||||||
3 | Does NCMP need (separate) version number from CPS-Core | Long term issue?Longterm: For the purpose of data-transformation the dmi-registry revision can be used to control upgrades in NCMP | |||||||
4 | Where to trigger implement upgrade action | Options:
| Developer agreed on Liquibase step 16 (depending issue #7) | ||||||
5 | What Dmi-registry yangmodel version we need to upgrade FROM and TO (latest) | Relate commit message: https://gerrit.onap.org/r/gitweb?p=cps.git;a=commit;h=7914c8924723092345e8b4d829f15d2a3a5c72c8 Was the data compatibility issue introduced by changelog/db/changes/14-loadData-dmi-registry-2022-05-10-schema-set.yaml | Luke Gleeson will found out and share with ETH team | ||||||
6 | 6 | Does short term solution need version | Check with Tony Finnerty see #2 | 7 | Technical debt: dmi-registry is installed as part of liquibase | stepsteps in CPS-Core. Can solution build upon this technical debt | Add liquibase | steps Preferred solution is to use Liquibase step ie build upon the technical debtsteps in CPS instead of a NVCMP only solution | Tony Finnerty and team agreed to use Liquibase steps for short term solution. But long term solution need to address this technical debt before any further update to the NCMP schema (registry model) Check with Tony Finnerty |
87 | Do we need to worry about rollback | requires specific statements to execute rollback | Yes |
| Team and stakeholder agreed rollback support is required in case upgrade fails at customer | ||||
89 | Size of customer data, can transformation cause delay/startup problems | kieran mccarthy estimates actual customer less then 1,000 nodes. | Luke Gleeson and Toine Siebelink agreed this solution should be tested with at least 1,000 registration in the DB (and communicate this with ETH. ETH should probably test it to because of their specific Helm configuration) | ||||||
910 | Describe/document upgrade and rollback procedures? | Is this needed or handle as part of orchestration install/upgrade procedures | Luke Gleeson and Toine Siebelink agreed, No, this should be part of standard kubernetes upgrade procedure and Liquibase should do its job (which wil be verified anyway, see decision #8) |
Short Term Solution
- Use Liquibase ID as CPS & NCMP 'version'
- Add Liquibase step 16 with a 'reversible''dummy' transformation
- Test liquibase upgrade
- Test liquibase rollback
...