From 7b4242750744f9b19ff27f1da24dd847a55af72b Mon Sep 17 00:00:00 2001 From: Jay Patel <78554593+jarpat@users.noreply.github.com> Date: Tue, 10 Oct 2023 14:59:13 -0400 Subject: [PATCH 1/5] feat: (IAC-1170) Update Default CERT_MANAGER_CHART_VERSION to 1.13.1 (#494) --- docs/CONFIG-VARS.md | 2 +- roles/baseline/defaults/main.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/CONFIG-VARS.md b/docs/CONFIG-VARS.md index dc9b2a4f..fc7baaee 100644 --- a/docs/CONFIG-VARS.md +++ b/docs/CONFIG-VARS.md @@ -363,7 +363,7 @@ Notes: | CERT_MANAGER_NAMESPACE | cert-manager Helm installation namespace | string | cert-manager | false | | baseline | | CERT_MANAGER_CHART_URL | cert-manager Helm chart URL | string | https://charts.jetstack.io/ | false | | baseline | | CERT_MANAGER_CHART_NAME| cert-manager Helm chart name | string | cert-manager| false | | baseline | -| CERT_MANAGER_CHART_VERSION | cert-manager Helm chart version | string | 1.11.0 | false | | baseline | +| CERT_MANAGER_CHART_VERSION | cert-manager Helm chart version | string | 1.13.1 | false | | baseline | | CERT_MANAGER_CONFIG | cert-manager Helm values | string | See [this file](../roles/baseline/defaults/main.yml) for more information. | false | | baseline | Notes: diff --git a/roles/baseline/defaults/main.yml b/roles/baseline/defaults/main.yml index 94ada303..d9cd7636 100644 --- a/roles/baseline/defaults/main.yml +++ b/roles/baseline/defaults/main.yml @@ -13,7 +13,7 @@ CERT_MANAGER_NAME: cert-manager CERT_MANAGER_NAMESPACE: cert-manager CERT_MANAGER_CHART_NAME: cert-manager CERT_MANAGER_CHART_URL: https://charts.jetstack.io/ -CERT_MANAGER_CHART_VERSION: 1.11.0 +CERT_MANAGER_CHART_VERSION: 1.13.1 CERT_MANAGER_CONFIG: installCRDs: "true" extraArgs: From bf748e8ab87a36cdaeb268693b1abdf45c4f25a7 Mon Sep 17 00:00:00 2001 From: David Houck Date: Tue, 10 Oct 2023 15:26:41 -0400 Subject: [PATCH 2/5] fix: (IAC-1169) deploy orchestration cmd in DAC docker container fails running DAC's kubectl binary (#492) --- roles/vdm/tasks/deploy.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/roles/vdm/tasks/deploy.yaml b/roles/vdm/tasks/deploy.yaml index 69762692..fd368132 100644 --- a/roles/vdm/tasks/deploy.yaml +++ b/roles/vdm/tasks/deploy.yaml @@ -50,7 +50,7 @@ state: directory - name: Deploy - Deploy SAS Viya environment: - PATH: "{{ env_path + ':' + ORCHESTRATION_TOOLING_PATH }}" + PATH: "{{ ORCHESTRATION_TOOLING_PATH + ':' + env_path }}" KUBECONFIG: "{{ KUBECONFIG }}" WORK_DIRECTORY: "{{ ORCHESTRATION_TOOLING_DIRECTORY }}/work" command: | @@ -66,7 +66,7 @@ - not V4_CFG_BELOW_THE_LINE - name: Deploy BLT - Deploy SAS Viya environment: - PATH: "{{ env_path + ':' + ORCHESTRATION_TOOLING_PATH }}" + PATH: "{{ ORCHESTRATION_TOOLING_PATH + ':' + env_path }}" KUBECONFIG: "{{ KUBECONFIG }}" WORK_DIRECTORY: "{{ ORCHESTRATION_TOOLING_DIRECTORY }}/work" EXPERIMENTAL_FEATURE_LOCAL_DEPLOYMENT_ASSETS: true From d9628e4d499f7273ba470175ddb194c6dab5e0bf Mon Sep 17 00:00:00 2001 From: Ritika Patil <94649368+riragh@users.noreply.github.com> Date: Wed, 11 Oct 2023 15:07:13 -0500 Subject: [PATCH 3/5] fix: (IAC-1072) Add AKS pod cidr to LOADBALANCER_SOURCE_RANGES (#496) --- roles/common/tasks/main.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/roles/common/tasks/main.yaml b/roles/common/tasks/main.yaml index 856fe44f..ef3eae9a 100644 --- a/roles/common/tasks/main.yaml +++ b/roles/common/tasks/main.yaml @@ -62,6 +62,16 @@ - tfstate.gke_pod_subnet_cidr is defined - tfstate.gke_pod_subnet_cidr.value|length > 0 - (tfstate.gke_pod_subnet_cidr.value) not in LOADBALANCER_SOURCE_RANGES + - name: tfstate - Add AKS pod cidr to LOADBALANCER_SOURCE_RANGES # noqa: name[casing] + set_fact: + LOADBALANCER_SOURCE_RANGES: "{{ LOADBALANCER_SOURCE_RANGES + [tfstate.aks_pod_cidr.value] }}" + when: + - tfstate.provider is defined + - tfstate.provider.value|length > 0 + - tfstate.provider.value == "azure" + - tfstate.aks_pod_cidr is defined + - tfstate.aks_pod_cidr.value|length > 0 + - (tfstate.aks_pod_cidr.value) not in LOADBALANCER_SOURCE_RANGES - name: tfstate - nfs endpoint # noqa: name[casing] set_fact: V4_CFG_RWX_FILESTORE_ENDPOINT: "{{ tfstate.rwx_filestore_endpoint.value }}" From a81551b38a88c07cb3d283c4b2bde37df626a84a Mon Sep 17 00:00:00 2001 From: Jay Patel <78554593+jarpat@users.noreply.github.com> Date: Thu, 12 Oct 2023 16:16:25 -0400 Subject: [PATCH 4/5] docs: (IAC-1202) Transfer Tooling viya4-deployment Supplemental Doc (#497) * initial doc * Update docs/Troubleshooting.md Co-authored-by: David Houck * Update docs/Troubleshooting.md Co-authored-by: David Houck * update links and wording * add experimental --------- Co-authored-by: David Houck --- docs/Troubleshooting.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/Troubleshooting.md b/docs/Troubleshooting.md index 1c5877fa..a866bd05 100644 --- a/docs/Troubleshooting.md +++ b/docs/Troubleshooting.md @@ -12,6 +12,9 @@ - [Deploying with the SAS Orchestration Tool using a Provider Based Kubernetes Configuration File](#deploying-with-the-sas-orchestration-tool-using-a-provider-based-kubernetes-configuration-file) - [SAS Risk Cirrus Solutions Multi-tenancy onboard failure](#sas-risk-cirrus-solutions-multi-tenancy-onboard-failure) - [Applying a New License for your SAS Viya Platform Deployment](#applying-a-new-license-for-your-sas-viya-platform-deployment) + * [PostgreSQL Data Transfer Tool for the SAS Viya Platform - viya4-deployment Post-Transfer Steps (Experimental)](#postgresql-data-transfer-tool-for-the-sas-viya-platform---viya4-deployment-post-transfer-steps-experimental) + + ## Debug Mode Debug mode can be enabled by adding "-vvv" to the end of the docker or ansible commands @@ -378,3 +381,27 @@ After downloading the license file perform the following steps: Information about licenses from the [SAS Viya Platform Operations Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=k8sag&docsetTarget=n14rkqa3cycmd0n1ub50k47x7lbb.htm) Note, these steps are only applicable for updating your license file, if you are going to be updating the SAS deployment or including additional products in your order we recommend that your perform your update manually. See this note in the [README](https://github.com/sassoftware/viya4-deployment#updating-sas-viya-manually) + + +## PostgreSQL Data Transfer Tool for the SAS Viya Platform - viya4-deployment Post-Transfer Steps (Experimental) + +### Symptom: + +You had an existing SAS Viya platform deployment that was created using the viya4-deployment project and configured to use Crunchy as the database, and you have now completed the manual steps outlined in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) to move your data over to an external PostgreSQL cluster. You now want to use the viya4-deployment project to manage your installation again. + +### Solution: + +1. After following the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" you manually added entries for the external PostgreSQL clusters into the kustomization.yaml and produced a file that includes details for **both** the internal Crunchy and external Postgres instance. You then built and applied the manifest so that the Viya deployment is reconfigured to point to the external Postgres instance. +2. The final step in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" asks you to manually remove entries to related to Crunchy and rebuild your manifests again. At this point in time you could instead remove the manual modifications you made to the kustomization.yaml and make changes to your `ansible-vars.yaml` so that the viya4-deployment project can manage your installation again. + 1. First remove any files you manually copied over to site-config to configure the external PostgreSQL clusters. Like `sas-bases/examples/postgres/postgres-user.env` and `site-config/postgres/dataserver-transformer.yaml`, viya4-deployment will be generating this for you. + * If as part of your data transfer, you provisioned your PostgreSQL clusters using any [Viya 4 IAC projects](https://github.com/search?q=org%3Asassoftware+viya4-iac-&type=repositories), then your PostgreSQL configration and connection information should already be present in the .tfstate file, so you don't need to add any entries in your `ansible-vars.yaml`. You should remove the `V4_CFG_POSTGRES_SERVERS` variable if it's still configuring an internal Crunchy instance like so: + ```yaml + # remove below + V4_CFG_POSTGRES_SERVERS: + default: + internal: true + ``` + * If as part of your data transfer, you provisioned your PostgreSQL clusters without the use of a Viya 4 IAC projects, then you will need to manually add definitions for each of your PostgreSQL clusters. You can see an example definition here in our [CONFIG-VARS.md documentation](https://github.com/sassoftware/viya4-deployment/blob/main/docs/CONFIG-VARS.md#postgresql) + 2. If your PostgreSQL Cluster requires a certificate for connection, in your `ansible-vars.yaml` ensure that `V4_CFG_TLS_TRUSTED_CA_CERTS` is set and points to either the certificate or a directory containing that certificate. + 3. In your `ansible-vars.yaml` set `DEPLOY` to false + 4. Run the ansible-playbook again with the `viya,install` tags. Since `DEPLOY` is set to false, the SAS Viya platform deployment will not be modified, however in your deployment directory you should see an updated kustomization.yaml with generated entries for your PostgreSQL clusters and those files should automatically be present in your site-config directory. \ No newline at end of file From cb4812ba2505602a54000af60864c818d7b2a66b Mon Sep 17 00:00:00 2001 From: David Houck Date: Thu, 19 Oct 2023 09:03:43 -0400 Subject: [PATCH 5/5] docs: (IAC-1202) PostgreSQL Transfer Tooling Supplemental Doc (#498) --- docs/Troubleshooting.md | 25 -------------- ...PostPostgreSQLDataTransfer_Experimental.md | 33 +++++++++++++++++++ 2 files changed, 33 insertions(+), 25 deletions(-) create mode 100644 docs/user/PostPostgreSQLDataTransfer_Experimental.md diff --git a/docs/Troubleshooting.md b/docs/Troubleshooting.md index a866bd05..d7b959ca 100644 --- a/docs/Troubleshooting.md +++ b/docs/Troubleshooting.md @@ -12,7 +12,6 @@ - [Deploying with the SAS Orchestration Tool using a Provider Based Kubernetes Configuration File](#deploying-with-the-sas-orchestration-tool-using-a-provider-based-kubernetes-configuration-file) - [SAS Risk Cirrus Solutions Multi-tenancy onboard failure](#sas-risk-cirrus-solutions-multi-tenancy-onboard-failure) - [Applying a New License for your SAS Viya Platform Deployment](#applying-a-new-license-for-your-sas-viya-platform-deployment) - * [PostgreSQL Data Transfer Tool for the SAS Viya Platform - viya4-deployment Post-Transfer Steps (Experimental)](#postgresql-data-transfer-tool-for-the-sas-viya-platform---viya4-deployment-post-transfer-steps-experimental) @@ -381,27 +380,3 @@ After downloading the license file perform the following steps: Information about licenses from the [SAS Viya Platform Operations Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=k8sag&docsetTarget=n14rkqa3cycmd0n1ub50k47x7lbb.htm) Note, these steps are only applicable for updating your license file, if you are going to be updating the SAS deployment or including additional products in your order we recommend that your perform your update manually. See this note in the [README](https://github.com/sassoftware/viya4-deployment#updating-sas-viya-manually) - - -## PostgreSQL Data Transfer Tool for the SAS Viya Platform - viya4-deployment Post-Transfer Steps (Experimental) - -### Symptom: - -You had an existing SAS Viya platform deployment that was created using the viya4-deployment project and configured to use Crunchy as the database, and you have now completed the manual steps outlined in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) to move your data over to an external PostgreSQL cluster. You now want to use the viya4-deployment project to manage your installation again. - -### Solution: - -1. After following the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" you manually added entries for the external PostgreSQL clusters into the kustomization.yaml and produced a file that includes details for **both** the internal Crunchy and external Postgres instance. You then built and applied the manifest so that the Viya deployment is reconfigured to point to the external Postgres instance. -2. The final step in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" asks you to manually remove entries to related to Crunchy and rebuild your manifests again. At this point in time you could instead remove the manual modifications you made to the kustomization.yaml and make changes to your `ansible-vars.yaml` so that the viya4-deployment project can manage your installation again. - 1. First remove any files you manually copied over to site-config to configure the external PostgreSQL clusters. Like `sas-bases/examples/postgres/postgres-user.env` and `site-config/postgres/dataserver-transformer.yaml`, viya4-deployment will be generating this for you. - * If as part of your data transfer, you provisioned your PostgreSQL clusters using any [Viya 4 IAC projects](https://github.com/search?q=org%3Asassoftware+viya4-iac-&type=repositories), then your PostgreSQL configration and connection information should already be present in the .tfstate file, so you don't need to add any entries in your `ansible-vars.yaml`. You should remove the `V4_CFG_POSTGRES_SERVERS` variable if it's still configuring an internal Crunchy instance like so: - ```yaml - # remove below - V4_CFG_POSTGRES_SERVERS: - default: - internal: true - ``` - * If as part of your data transfer, you provisioned your PostgreSQL clusters without the use of a Viya 4 IAC projects, then you will need to manually add definitions for each of your PostgreSQL clusters. You can see an example definition here in our [CONFIG-VARS.md documentation](https://github.com/sassoftware/viya4-deployment/blob/main/docs/CONFIG-VARS.md#postgresql) - 2. If your PostgreSQL Cluster requires a certificate for connection, in your `ansible-vars.yaml` ensure that `V4_CFG_TLS_TRUSTED_CA_CERTS` is set and points to either the certificate or a directory containing that certificate. - 3. In your `ansible-vars.yaml` set `DEPLOY` to false - 4. Run the ansible-playbook again with the `viya,install` tags. Since `DEPLOY` is set to false, the SAS Viya platform deployment will not be modified, however in your deployment directory you should see an updated kustomization.yaml with generated entries for your PostgreSQL clusters and those files should automatically be present in your site-config directory. \ No newline at end of file diff --git a/docs/user/PostPostgreSQLDataTransfer_Experimental.md b/docs/user/PostPostgreSQLDataTransfer_Experimental.md new file mode 100644 index 00000000..5a7441ce --- /dev/null +++ b/docs/user/PostPostgreSQLDataTransfer_Experimental.md @@ -0,0 +1,33 @@ +## Post PostgreSQL Data Transfer steps for viya4-deployment (Experimental) + +### Using IAC to create an external PostgreSQL database server +If you prefer to use the IAC project used to create your cluster to create an external PostgreSQL database server, refer to IAC project link below corresponding to your cloud environment for PostgreSQL database server configuration examples. + +**Note**: Before using IAC to create a new external PostgreSQL database server, we recommend that you follow the steps to [Stop a SAS Viya Platform Deployment](https://documentation.sas.com/?cdcId=sasadmincdc&cdcVersion=v_044&docsetId=calchkadm&docsetTarget=p17xfmmjjkma1dn1b5dcx3e5ejxq.htm#p0butgo7gtfyi0n14umtfv0voydt). Once the external PostgreSQL database server has been created by IAC, follow the steps to [Start a SAS Viya Platform Deployment](https://documentation.sas.com/?cdcId=sasadmincdc&cdcVersion=v_044&docsetId=calchkadm&docsetTarget=p17xfmmjjkma1dn1b5dcx3e5ejxq.htm#p0butgo7gtfyi0n14umtfv0voydt). + +[Azure PostgreSQL Server](https://github.com/sassoftware/viya4-iac-azure/blob/main/docs/CONFIG-VARS.md#postgres-servers) + +[AWS PostgreSQL Server](https://github.com/sassoftware/viya4-iac-aws/blob/main/docs/CONFIG-VARS.md#postgresql-server) + +[GCP PostgreSQL Server](https://github.com/sassoftware/viya4-iac-gcp/blob/main/docs/CONFIG-VARS.md#postgres-servers) + +### Situation: + +You had an existing SAS Viya platform deployment that was created using the viya4-deployment project and configured to use Crunchy as the database, and you have now completed the manual steps outlined in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) to move your data over to an external PostgreSQL cluster. You now want to use the viya4-deployment project to manage your installation again. + +### Recommended Steps: + +1. After following the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" you manually added entries for the external PostgreSQL clusters into the kustomization.yaml and produced a file that includes details for **both** the internal Crunchy and external Postgres instance. You then built and applied the manifest so that the Viya deployment is reconfigured to point to the external Postgres instance. +2. The final step in the [PostgreSQL Data Transfer Guide](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=pgdatamig&docsetTarget=titlepage.htm) under "Steps for Crunchy Data 5" asks you to manually remove entries to related to Crunchy and rebuild your manifests again. At this point in time you could instead remove the manual modifications you made to the kustomization.yaml and make changes to your `ansible-vars.yaml` so that the viya4-deployment project can manage your installation again. + 1. First remove any files you manually copied over to site-config to configure the external PostgreSQL clusters. Like `sas-bases/examples/postgres/postgres-user.env` and `site-config/postgres/dataserver-transformer.yaml`, viya4-deployment will be generating this for you. + * If as part of your data transfer, you provisioned your PostgreSQL clusters using any [Viya 4 IAC projects](https://github.com/search?q=org%3Asassoftware+viya4-iac-&type=repositories), then your PostgreSQL configuration and connection information should already be present in the .tfstate file, so you don't need to add those entries in your `ansible-vars.yaml`. You should modify the `V4_CFG_POSTGRES_SERVERS` variable if it's still configured to use an internal Crunchy instance like so: + ```yaml + # modify as below to use external instance + V4_CFG_POSTGRES_SERVERS: + default: + internal: false + ``` + * If as part of your data transfer, you provisioned your PostgreSQL clusters without the use of a Viya 4 IAC projects, then you will need to manually add definitions for each of your PostgreSQL clusters. You can see an example definition here in our [CONFIG-VARS.md documentation](https://github.com/sassoftware/viya4-deployment/blob/main/docs/CONFIG-VARS.md#postgresql) + 2. If your PostgreSQL Cluster requires a certificate for connection, in your `ansible-vars.yaml` ensure that `V4_CFG_TLS_TRUSTED_CA_CERTS` is set and points to either the certificate or a directory containing that certificate. + 3. In your `ansible-vars.yaml` set `DEPLOY` to false + 4. Run the ansible-playbook again with the `viya,install` tags. Since `DEPLOY` is set to false, the SAS Viya platform deployment will not be modified, however in your deployment directory you should see an updated kustomization.yaml with generated entries for your PostgreSQL clusters and those files should automatically be present in your site-config directory. \ No newline at end of file