Version 3.5 CloudOne Dataspace CI/CD Pipeline Upgrade

Version 3.5 of the CloudOne Dataspace CI/CD Pipelines introduces a number of important changes and improvements, including the following:

• Single unified pipeline
• Exposing database to corp network.
• Extensibility

Steps to upgrade dataspace to version 3.5

In addition to the new features, necessary changes were made to the underlying pipeline logic and to the Helm charts that drive the definition of Kubernetes objects deployed by CloudOne, requiring changes to be made to the project's azure-pipelines.yml file, to existing Helm charts and potentially requiring extra steps to complete updates to pre-existing database at build an/or deployment time.

MariaDB upgrade to version 3.5

Follow the below steps to upgrade MariaDB pipeline to use version 3.5

1. Mulitple changes have been made to the Mariadb catalog, so the easy way to upgrade is to download the copy of mariadb v3.5 code from devexp project.

   

2. Connect to your database repo and create the new branch. For example "feature/v35upgrade".
3. Clone the repo to your local machine using git.
4. Checkout newly created branch. For example "feature/v35upgrade".
5. Before making the changes let's go ahead and take the backup of the existing repo data.

6. Make a note of database secret detail and it's values from OpenShift. We need this details to update the newly created props variable group.

   

   

   

7. Update the values of .props variable group in pipeline library.

   

   

   

8. Take note of chart dir name detail from azure-pipelines.yaml

   

9. Overwrite "feature/v35upgrade" branch with devexp v3.5 data.

10. Let's edit the azure-pipelines.yaml and update the following details.

    update **template:** value under **extends:** section. replace **dbaas/devexp-mariadb.yml@spaces** with **dbaas/<dataspace repo name>.yml@spaces**
    update **appVersion:** by increment the verion number.
    update **overrideFiles:** value under **helm:** section by replacing **devexp-mariadb** with your chart name.

    

11. Edit values.yaml, values.workspace.yaml and values.dataspace.yaml files and udpate the following section data from the files from your backup taken during step 5.

    replace devexp value with your 3 application 3 letter code for **code:** under **app:** section. 
    storage size detail under **persistence:** section
    resource details under **resource:** section

    

12. There is a known issue in Kubernetes where, when significant annotation changes have been made for a new deployment of an object, Kubernetes will fail to handle the replacement of the deployed objects correctly and will, as a result, fail to deploy an updated version of an application. Because of a number of changes made to the deployment attributes and annotations under version 3.5 of the CI/CD pipeline, it is possible in many cases that an database previously deployed before version 3.5 will fail to update when run under a version 3.5 pipeline. If this should happen, the resolution is to simply go through every target Kubernetes namespace, manually remove the database statefulset, and then redeploy the updated version of the database under the version 3.5 pipeline.

MongoDB upgrade to version 3.5

Follow the below steps to upgrade MongoDB pipeline to use version 3.5

1. Mulitple changes have been made to the MongoDB catalog, so the easy way to upgrade is to download the copy of mongodb v3.5 code from devexp project.

   

2. Connect to your database repo and create the new branch. For example "feature/v35upgrade".
3. Clone the repo to your local machine.
4. Checkout newly created branch. For example "feature/v35upgrade".
5. Before making the changes let's go ahead and take the backup of the existing repo data.

6. Make a note of database secret detail and it's values from OpenShift. We need this details to update the newly created props variable group.

   

   

   

7. Update the values of .props variable group in pipeline library.

   

   

   

8. Take note of chart dir name detail from azure-pipelines.yaml

   

9. Overwrite "feature/v35upgrade" branch with devexp v3.5 data.

10. Let's edit the azure-pipelines.yaml and update the following details.

    update **template:** value under **extends:** section. replace **dbaas/devexp-mongodb.yml@spaces** with **dbaas/<dataspace name>.yml@spaces**
    update **appVersion:** by increment the verion number.
    update **overrideFiles:** value under **helm:** section by replacing **devexp-mongodb** with your chart name.

    

11. Edit values.yaml, values.workspace.yaml and values.dataspace.yaml files and udpate the following section data from the files from your backup taken during step 5.

    replace devexp value with your 3 application 3 letter code for **code:** under **app:** section. 
    storage size detail under **persistence:** section
    resource details under **resource:** section

    

12. There is a known issue in Kubernetes where, when significant annotation changes have been made for a new deployment of an object, Kubernetes will fail to handle the replacement of the deployed objects correctly and will, as a result, fail to deploy an updated version of an application. Because of a number of changes made to the deployment attributes and annotations under version 3.5 of the CI/CD pipeline, it is possible in many cases that an database previously deployed before version 3.5 will fail to update when run under a version 3.5 pipeline. If this should happen, the resolution is to simply go through every target Kubernetes namespace, manually remove the database statefulset, and then redeploy the updated version of the database under the version 3.5 pipeline.

PostgreSQL upgrade to version 3.5

Follow the below steps to upgrade PostgreSQL pipeline to use version 3.5

1. Mulitple changes have been made to the Postgresql catalog, so the easy way to upgrade is to download the copy of postgresql v3.5 code from devexp project.

   

2. Connect to your database repo and create the new branch. For example "feature/v35upgrade".
3. Clone the repo to your local machine.
4. Checkout newly created branch. For example "feature/v35upgrade".
5. Before making the changes let's go ahead and take the backup of the existing repo data.

6. Make a note of database secret detail and it's values from OpenShift. We need this details to update the newly created props variable group.

   

   

   

7. Update the values of .props variable group in pipeline library.

   

   

   

8. Take note of chart dir name detail from azure-pipelines.yaml

   

9. Overwrite "feature/v35upgrade" branch with devexp v3.5 data.

10. Let's edit the azure-pipelines.yaml and update the following details.

    update **template:** value under **extends:** section. replace **dbaas/devexp-postgresql.yml@spaces** with **dbaas/<dataspace repo name>.yml@spaces**
    update **appVersion:** by increment the verion number.
    update **overrideFiles:** value under **helm:** section by replacing **devexp-postgresql** with your chart name.

    

11. Edit values.yaml, values.workspace.yaml and values.dataspace.yaml files and udpate the following section data from the files from your backup taken during step 5.

    replace devexp value with your 3 application 3 letter code for **code:** under **app:** section. 
    storage size detail under **persistence:** section
    resource details under **resource:** section

    

12. There is a known issue in Kubernetes where, when significant annotation changes have been made for a new deployment of an object, Kubernetes will fail to handle the replacement of the deployed objects correctly and will, as a result, fail to deploy an updated version of an application. Because of a number of changes made to the deployment attributes and annotations under version 3.5 of the CI/CD pipeline, it is possible in many cases that an database previously deployed before version 3.5 will fail to update when run under a version 3.5 pipeline. If this should happen, the resolution is to simply go through every target Kubernetes namespace, manually remove the database statefulset, and then redeploy the updated version of the database under the version 3.5 pipeline.

Redis upgrade to version 3.5

Follow the below steps to upgrade Redis pipeline to use version 3.5

1. Mulitple changes have been made to the Redis catalog, so the easy way to upgrade is to download the copy of redis v3.5 code from devexp project.

   

2. Connect to your database repo and create the new branch. For example "feature/v35upgrade".
3. Clone the repo to your local machine.
4. Checkout newly created branch. For example "feature/v35upgrade".
5. Before making the changes let's go ahead and take the backup of the existing repo data.

6. Make a note of database secret detail and it's values from OpenShift. We need this details to update the newly created props variable group.

   

   

   

7. Update the values of .props variable group in pipeline library.

   

   

   

8. Take note of chart dir name detail from azure-pipelines.yaml

   

9. Overwrite "feature/v35upgrade" branch with devexp v3.5 data.

10. Let's edit the azure-pipelines.yaml and update the following details.

    update **template:** value under **extends:** section. replace **dbaas/devexp-redis.yml@spaces** with **dbaas/<dataspace repo name>.yml@spaces**
    update **appVersion:** by increment the verion number.
    update **overrideFiles:** value under **helm:** section by replacing **devexp-redis** with your chart name.

    

11. Edit values.yaml, values.workspace.yaml and values.dataspace.yaml files and udpate the following section data from the files from your backup taken during step 5.

    replace devexp value with your 3 application 3 letter code for **code:** under **app:** section. 
    storage size detail under **persistence:** section
    resource details under **resource:** section

    

12. There is a known issue in Kubernetes where, when significant annotation changes have been made for a new deployment of an object, Kubernetes will fail to handle the replacement of the deployed objects correctly and will, as a result, fail to deploy an updated version of an application. Because of a number of changes made to the deployment attributes and annotations under version 3.5 of the CI/CD pipeline, it is possible in many cases that an database previously deployed before version 3.5 will fail to update when run under a version 3.5 pipeline. If this should happen, the resolution is to simply go through every target Kubernetes namespace, manually remove the database statefulset, and then redeploy the updated version of the database under the version 3.5 pipeline.

Enterprise MongoDB upgrade to version 3.5

Follow the below steps to upgrade Enterprise MongoDB pipeline to use version 3.5

1. Mulitple changes have been made to the Enterprise mongo catalog, so the easy way to upgrade is to download the copy of enterprise mongodb v3.5 code from devexp project.

   

2. Connect to your database repo and create the new branch. For example "feature/v35upgrade".
3. Clone the repo to your local machine.
4. Checkout newly created branch. For example "feature/v35upgrade".
5. Before making the changes let's go ahead and take the backup of the existing repo data.

6. Make a note of database secret detail and it's values from OpenShift. We need this details to update the newly created props variable group.

   

   

   

7. Update the values of .props variable group in pipeline library.

   

   

   

8. Take note of chart dir name detail from azure-pipelines.yaml

   

9. Overwrite "feature/v35upgrade" branch with devexp v3.5 data.

10. Let's edit the azure-pipelines.yaml and update the following details.

    update **template:** value under **extends:** section. replace **dbaas/devexp-enterprise-mongo.yml@spaces** with **dbaas/<dataspace repo name>.yml@spaces**
    update **appVersion:** by increment the verion number.
    update **overrideFiles:** value under **helm:** section by replacing **devexp-enterprise-mongo** with your chart name.

    

11. Edit values.yaml, values.workspace.yaml and values.dataspace.yaml files and udpate the following section data from the files from your backup taken during step 5.

    replace devexp value with your 3 application 3 letter code for **code:** under **app:** section. 
    storage size detail under **persistence:** section
    resource details under **resource:** section

    

12. There is a known issue in Kubernetes where, when significant annotation changes have been made for a new deployment of an object, Kubernetes will fail to handle the replacement of the deployed objects correctly and will, as a result, fail to deploy an updated version of an application. Because of a number of changes made to the deployment attributes and annotations under version 3.5 of the CI/CD pipeline, it is possible in many cases that an database previously deployed before version 3.5 will fail to update when run under a version 3.5 pipeline. If this should happen, the resolution is to simply go through every target Kubernetes namespace, manually remove the database statefulset, and then redeploy the updated version of the database under the version 3.5 pipeline.

Exposing databases outside of OpenShift/Kubernetes cluster.

In version 3.5 ambassador mapping is enabled by defining new Helm chart values. We have ambassador configured in AWS and On-Prem(HCI).

Each ambassador uses a different DNS subdomain in which to place the exposed hostnames. At the time of this writing, there are 2 subdomains available for database:

In order to enable Ambassador mappings, set the following YAML values to true in the Helm chart values (for example, in a values.hostspace.yaml file):

• ambassador.dbaas.enabled - to enable Ambassador mappings for dataspace.

ambassador:
  tls:
    secret:
  dbaas:
    enabled: true
    domain: 

*NOTE: The values of ambassador.dbaas.domain and ambassador.tls.secret are left empty in the Helm chart as these are supplied by variables defined in variable groups in Azure DevOps based on the workspace or dataspace to which the database is deployed by the CI/CD pipeline.*

The ambassador generated hostname format will be like,

• -.prd01d.cloudone.netapp.com for AWS
• -.prd02d.cloudone.netapp.com for On-Prem HCI

*NOTE: You need to use stunnel to connect to database outside of kubernetes cluster using the exposed hostname.

Here is the sample stunnel.conf file entry for mariadb database.

client = yes
sslVersion = TLSv1.2
output = /var/log/stunnel.log
debug = 7

[mariadb-aws]
accept = 127.0.0.1:3306
connect = mariadb-devexp-stg-1.prd01d.cloudone.netapp.com:3306
sni = mariadb-devexp-stg-1.prd01d.cloudone.netapp.com

[mariadb-onprem]
accept = 127.0.0.1:3307
connect = mariadb-devexp-stg-2.prd02d.cloudone.netapp.com:3306
sni = mariadb-devexp-stg-2.prd02d.cloudone.netapp.com