Tri: The script installSdncDb.sh that is currently run in the post-install hook is meant to create and initialize the SDNC database. It doesn’t really care for existing data, although it is intended to be idempotent (so if you run it on an existing database, it shouldn’t break anything). We don’t currently have any scripts that do a proper backup/restore on upgrade – that is frankly a feature we’ve been carrying for several releases now that we have been unable to address due to lack of resources.
To do an SDNC upgrade, there are really 2 sets of data that need to be cared for: 1. Data stored in mariadb 2. Data stored in OpenDaylight’s in-memory data store (aka MD-SAL) For data stored in MariaDB, the approach is fairly straight forward: before the upgrade, we’d need to do a mysqldump to dump the sdnctl database, then after the upgrade, we’d want to import that data. The installSdndb.sh script is already designed to initialize from a file created by mysqldump, so we’d just need to update that script slightly to change the name of the dump file it loads so that it loads the dump saved before the upgrade. Data stored in the OpenDaylight in-memory data store is a bit more complicated. We currently save that data in a persistent data volume, so that it can survive container restarts. However, the format OpenDaylight uses is not terribly portable. If an ONAP release includes an OpenDaylight upgrade OR even a change to our internal data models, we would not be able to use that data in the existing PV in the new release. Instead, we’d have to: 1. Export the existing data before the upgrade , via the OpenDaylight ‘daexim’ function (a RESTCONF interface) 2. After the old pod is down and before the new pod comes up, remove and recreate those pvs , so they come up clean. 3. After the new pods are started, run a conversion script on the exported data if necessary, then import it. That “run a conversion script” step is key. Most OpenDaylight releases – even service releases – introduce breaking changes , which can break existing data. For example, in Sodium the release we’re moving to in Guilin), there is a change such that any field defined as a 64 bit integer is stored as a string - which means we’d need to convert the exported data to add quotes around any values declared as 64 bit integers. Without that step, the import would fail. I’d be happy to work with you to provide the proper scripts in our SDNC docker to do the import, export and conversion, if you can help with how to trigger them with the right helm hooks. Dan From: Tri Nguyen <[email protected]> Date: Wednesday, May 6, 2020 at 12:06 PM To: "TIMONEY, DAN" <[email protected]>, "[email protected]" <[email protected]>, Krzysztof Opasiak <[email protected]> Cc: onap-discuss <[email protected]> Subject: SDNC rolling upgrade Hi Dan, I’m Tri Nguyen from Tata Communications. I am working on the rolling upgrade of SDNC, which has the JIRA Ticket https://jira.onap.org/browse/OOM-2273<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_OOM-2D2273&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=etaOHQmMT1vP7KEImFN-CLdrpMzGuhcxqRteVwYTpfs&s=LSbUC5_tEa_trtJVCfdrCqWjWWzRth9kC6HwLh96iP0&e=>. I would like to ask an issue relate to the SDNC upgrade from release E to F. In the code of SDNC release F, there is a script file named “InstallSDNC.sh” which is included in the Job Post-install helm hook template. This is used to initialize a brand new database of SDNC inside mariadb, a.k.a sdnctl. This is the case when we install a new SDNC application in release F. However, when we upgrade SDNC from release E to release F, database sdnctl in release E is migrated to release F. There are two events required some anticipation: * Job Post-install helm hook trigger InstallSDNC.sh will not be executed. * Old data sdnctl from release E will be replicated to release F Due to these events, will there be any incompatibility using old data sdnctl from release E by the SDNC of release F? I notice that the docker image of SDNC is different between release E and F, so that I don’t know if the data populated in release F using Job Post-install helm hook Is any different from data in release E. For example, is there any new structure of table in sdnctl in release F compared to release E? Assuming that we have a few user-customized artifacts that are developed by SDNC in release E. When we migrate the data of artifacts to release F using rolling upgrade, will SDNC continue to query old data of these artifacts successfully? Since these questions are very specific to SDNC project, I hope you can give us some information to address these issues for a proper SDNC upgrade. Hope to hear from you. Regards Tri -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21086): https://lists.onap.org/g/onap-discuss/message/21086 Mute This Topic: https://lists.onap.org/mt/74031709/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
