docs: (PSKD-710) Update GCP refs in documentation

README.md

@@ -50,7 +50,7 @@ The viya4-deployment playbook requires some infrastructure.
 You can either bring your own Kubernetes cluster or use one of the SAS Viya 4 IaC projects to create a cluster using Terraform scripts:
   - [SAS Viya 4 IaC for AWS](https://github.com/sassoftware/viya4-iac-aws)
   - [SAS Viya 4 IaC for Microsoft Azure](https://github.com/sassoftware/viya4-iac-azure)
-  - [SAS Viya 4 IaC for Google Cloud Platform](https://github.com/sassoftware/viya4-iac-gcp)
+  - [SAS Viya 4 IaC for Google Cloud](https://github.com/sassoftware/viya4-iac-gcp)
 
 
 #### Storage
@@ -100,7 +100,7 @@ cd viya4-deployment
 
 See [Ansible Cloud Authentication](./docs/user/AnsibleCloudAuthentication.md) for details.
 
-**NOTE:** At this time, additional setup is only required for GCP with external PostgreSQL.
+**NOTE:** At this time, additional setup is only required for Google Cloud with external PostgreSQL.
 
 ### Customize Input Values
 
@@ -118,7 +118,7 @@ The value is the path to a standard SAS Viya platform sitedefault file. If none
 
 The Kubernetes access configuration file. If you used one of the SAS Viya 4 IaC projects to provision your cluster, this value is not required.
 
-If you used the [viya4-iac-gcp](https://github.com/sassoftware/viya4-iac-gcp) project to create a provider based kubeconfig file to access your GKE cluster, refer to [kubernetes configuration file types](./docs/user/Kubeconfig.md) for instructions on using a GCP provider based kubeconfig file with the viya4-deployment project.
+If you used the [viya4-iac-gcp](https://github.com/sassoftware/viya4-iac-gcp) project to create a provider based kubeconfig file to access your GKE cluster, refer to [kubernetes configuration file types](./docs/user/Kubeconfig.md) for instructions on using a Google Cloud provider based kubeconfig file with the viya4-deployment project.
 
 #### Terraform State File
 
@@ -278,6 +278,6 @@ See the [Troubleshooting](./docs/Troubleshooting.md) page.
 - [SAS Viya Resource Guide](https://github.com/sassoftware/viya4-resource-guide)
 - [SAS Viya 4 Infrastructure as Code (IaC) for Amazon Web Services (AWS)](https://github.com/sassoftware/viya4-iac-aws)
 - [SAS Viya 4 Infrastructure as Code (IaC) for Microsoft Azure](https://github.com/sassoftware/viya4-iac-azure)
-- [SAS Viya 4 Infrastructure as Code (IaC) for Google Cloud Platform (GCP)](https://github.com/sassoftware/viya4-iac-gcp)
+- [SAS Viya 4 Infrastructure as Code (IaC) for Google Cloud](https://github.com/sassoftware/viya4-iac-gcp)
 - [SAS Viya Monitoring for Kubernetes](https://github.com/sassoftware/viya4-monitoring-kubernetes)
 - [SAS Viya Orders CLI](https://github.com/sassoftware/viya4-orders-cli)

docs/CONFIG-VARS.md

@@ -11,7 +11,7 @@ Supported configuration variables are listed in the table below.  All variables
     - [RWX Filestore](#rwx-filestore)
     - [Azure](#azure)
     - [AWS](#aws)
-    - [GCP](#gcp)
+    - [Google Cloud](#google-cloud)
   - [SAS Software Order](#sas-software-order)
   - [SAS API Access](#sas-api-access)
   - [Container Registry Access](#container-registry-access)
@@ -115,7 +115,7 @@ When V4_CFG_MANAGE_STORAGE is set to `true`, the `sas` and `pg-storage` storage
 
 When V4_CFG_MANAGE_STORAGE is set to `true`, the efs-provisioner is deployed, the `sas` and `pg-storage` storage classes are created (EFS or NFS).
 
-### GCP
+### Google Cloud
 
 When V4_CFG_MANAGE_STORAGE is set to `true`, the `sas` and `pg-storage` storage classes are created (Google Filestore or NFS).
 
@@ -275,9 +275,9 @@ V4_CFG_POSTGRES_SERVERS:
 | password | External postgres password | string | | false | Required for external postgres servers | viya |
 | fqdn | External postgres ip/fqdn | string | | false | Required for external postgres servers | viya |
 | server_port | External postgres port | string | 5432 | false | | viya |
-| ssl_enforcement_enabled | Require ssl connection to external postgres | bool | | false | Required for external postgres servers. Ignored on GCP when using cloud sql | viya |
-| connection_name | External postgres database connection name | string | | false | Required for using cloud-sql-proxy on gcp. See [ansible cloud authentication](user/AnsibleCloudAuthentication.md) | viya |
-| service_account | External service account for postgres connectivity | string | | false | Required for using cloud-sql-proxy on gcp. See [ansible cloud authentication](user/AnsibleCloudAuthentication.md) | viya |
+| ssl_enforcement_enabled | Require ssl connection to external postgres | bool | | false | Required for external postgres servers. Ignored on Google Cloud when using cloud sql | viya |
+| connection_name | External postgres database connection name | string | | false | Required for using cloud-sql-proxy on Google Cloud. See [ansible cloud authentication](user/AnsibleCloudAuthentication.md) | viya |
+| service_account | External service account for postgres connectivity | string | | false | Required for using cloud-sql-proxy on Google Cloud. See [ansible cloud authentication](user/AnsibleCloudAuthentication.md) | viya |
 | postgres_pvc_storage_size | Size of the internal postgreSQL PVCs | string | 128Gi | false |This value can be changed but not decreased after the initial deployment. Supported for cadence versions 2022.10 and later. Only for internal databases.| viya |
 | backrest_pvc_storage_size | Size of the internal pgBackrest PVCs | string | 128Gi | false | This value can be changed but not decreased after the initial deployment. Supported for cadence versions 2022.10 and later. Only for internal databases.| viya |
 | postgres_pvc_access_mode | Access mode for the PostgreSQL PVCs | string | ReadWriteOnce | false | Supported values: [`ReadWriteOnce`,`ReadWriteMany`]. This value cannot be changed after the initial deployment. Supported for cadence versions 2022.10 and later. Only for internal databases.| viya |
@@ -382,7 +382,7 @@ Notes:
 
 ### Cluster Autoscaler
 
-Cluster-autoscaler is currently only used for AWS EKS clusters. GCP GKE and Azure AKS already have autoscaling features enabled by default.
+Cluster-autoscaler is currently only used for AWS EKS clusters. Google GKE and Azure AKS already have autoscaling features enabled by default.
 
 | Name | Description | Type | Default | Required | Notes | Tasks |
 | :--- | ---: | ---: | ---: | ---: | ---: | ---: |
@@ -424,7 +424,7 @@ The EBS CSI driver is currently only used for kubernetes v1.23 or later AWS EKS
 
 ### Metrics Server
 
-Kubernetes Metrics Server installation is currently only applicable for AWS EKS clusters. GCP GKE and Azure AKS already have a metric server provided by default.
+Kubernetes Metrics Server installation is currently only applicable for AWS EKS clusters. Google GKE and Azure AKS already have a metric server provided by default.
 
 | Name | Description | Type | Default | Required | Notes | Tasks |
 | :--- | ---: | ---: | ---: | ---: | ---: | ---: |

docs/Troubleshooting.md

@@ -148,7 +148,7 @@ Note: If you used viya4-iac-aws:5.6.0 or newer to create your infrastructure, th
       * Once you are on the Roles page search for "cluster-autoscaler" and choose the one for your cluster.
       * Under the "Permissions" tab expand the "eks-worker-autoscaling" policy
       * Update the `eksWorkerAutoscalingAll` & `eksWorkerAutoscalingOwn` Sids so that it matches the IAM policy as recommend by the [kubernetes/autoscaler documentation](https://github.com/kubernetes/autoscaler/blob/cluster-autoscaler-chart-9.25.0/cluster-autoscaler/cloudprovider/aws/README.md). Make sure to leave the `Condition` block as is.
-        * Switch the repo to the tag of the version of the cluster-autoscaler you are deploying, so that you are viewing the correct documentation.
+        * Switch the repository to the tag of the version of the cluster-autoscaler you are deploying, so that you are viewing the correct documentation.
 2. Scale the `cluster-autoscaler-aws-cluster-autoscaler` deployment back to 1
       ```bash
       kubectl scale --replicas=1 deployment/cluster-autoscaler-aws-cluster-autoscaler
@@ -290,9 +290,9 @@ INGRESS_NGINX_CONFIG:
 ## Deploying with the SAS Orchestration Tool using a Provider Based Kubernetes Configuration File
 
 ### Symptom:
-While deploying the SAS Viya platform into a GCP OR AWS cluster using a provider based kubernetes configuration file and setting `V4_DEPLOYMENT_OPERATOR_ENABLED: false` in your `ansible-vars.yaml`, the following error message is encountered:
+While deploying the SAS Viya platform into Google Cloud OR AWS cluster using a provider based kubernetes configuration file and setting `V4_DEPLOYMENT_OPERATOR_ENABLED: false` in your `ansible-vars.yaml`, the following error message is encountered:
 
-In GCP:
+In Google Cloud:
   ```bash
 Error: Cannot create client for namespace 'deploy'
  Caused by:
@@ -321,7 +321,7 @@ Error: Cannot create client for namespace 'deploy'
 
 ### Diagnosis:
 
-If you are using a provider based kubernetes configuration file; one that relies on external binaries from the cloud provider to authenticate into the kubernetes cluster ([AWS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html) & [GCP](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication)), there are deployment constraints you need to consider when planning your SAS Viya platform deployment when using this project. If you are using a "kubernetes service account and cluster role binding" or "static" based kubernetes configuration file it will be compatible will all SAS Viya platform deployment methods as well as ways to execute this project, and the statements below are not applicable.
+If you are using a provider based kubernetes configuration file; one that relies on external binaries from the cloud provider to authenticate into the kubernetes cluster ([AWS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html) & [Google Cloud](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication)), there are deployment constraints you need to consider when planning your SAS Viya platform deployment when using this project. If you are using a "kubernetes service account and cluster role binding" or "static" based kubernetes configuration file it will be compatible will all SAS Viya platform deployment methods as well as ways to execute this project, and the statements below are not applicable.
 
 Some background information, using the `V4_DEPLOYMENT_OPERATOR_ENABLED` flag  in your `ansible-vars.yaml` you are able to control the method of deployment that this project will use to deploy SAS Viya.
 * `V4_DEPLOYMENT_OPERATOR_ENABLED: true`, the [SAS Viya Platform Deployment Operator](https://documentation.sas.com/?cdcId=itopscdc&cdcVersion=default&docsetId=itopscon&docsetTarget=p0839p972nrx25n1dq264egtgrcq.htm) will be installed into the cluster and used to deploy the SAS Viya platform
@@ -335,7 +335,7 @@ The combination of setting `V4_DEPLOYMENT_OPERATOR_ENABLED: false` and running d
 
 When the `sas-orchestration` tooling is run (as a Docker container) to deploy SAS Viya into the cluster, the required binaries from the cloud provider for authentication are not present, meaning that the tooling will not be able to connect to the cluster to perform the deployment.
 
-When running the viya4-deployment project as a Docker container the `sas-orchestration` tooling is run in a slightly different manner to get around this limitation. We make use of `skopeo` to exact the contents of the `sas-orchestration` tooling image directly into our running viya4-deployment container. Since in our Dockerfile we include the installation of the required authentications binaries for GCP and AWS, the `sas-orchestration` tooling is able to make use of them and successfully connect to the kubernetes cluster.
+When running the viya4-deployment project as a Docker container the `sas-orchestration` tooling is run in a slightly different manner to get around this limitation. We make use of `skopeo` to exact the contents of the `sas-orchestration` tooling image directly into our running viya4-deployment container. Since in our Dockerfile we include the installation of the required authentications binaries for Google Cloud and AWS, the `sas-orchestration` tooling is able to make use of them and successfully connect to the kubernetes cluster.
 
 ### Solution:
 

docs/user/AnsibleCloudAuthentication.md

@@ -2,21 +2,21 @@
 
 The docker container contains cloud CLIs needed for interacting with the various clouds.
 
-## GCP
+## Google Cloud
 
-When using external postgres in GCP, we default to using [Google Cloud SQL proxy](https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine). For security the setup is via a workload identity configuration. This requires the following vars to be set:
+When using external postgres in Google Cloud, we default to using [Google Cloud SQL proxy](https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine). For security the setup is via a workload identity configuration. This requires the following vars to be set:
 
 ### V4_CFG_POSTGRES_CONNECTION_NAME
 
-Name of the SQL cluster connection, as listed in the GCP console.
+Name of the SQL cluster connection, as listed in the Google Cloud console.
 
 ### V4_CFG_POSTGRES_SERVICE_ACCOUNT
 
-Name of service account in GCP that has the cloudsql.admin role. This account will be mapped to a Kubernetes service account, thus granting the SQL proxy access, via workload identity, to the SQL server.
+Name of service account in Google Cloud that has the cloudsql.admin role. This account will be mapped to a Kubernetes service account, thus granting the SQL proxy access, via workload identity, to the SQL server.
 
 ### V4_CFG_CLOUD_SERVICE_ACCOUNT_NAME 
 
-Name of service account in GCP that has the iam.serviceAccountAdmin role. This account will be used to setting up the sql proxy's Google service account mapping to the kubernetes service account
+Name of service account in Google Cloud that has the iam.serviceAccountAdmin role. This account will be used to setting up the sql proxy's Google service account mapping to the kubernetes service account
 
 ### V4_CFG_CLOUD_SERVICE_ACCOUNT_AUTH 
 

docs/user/AnsibleUsage.md

@@ -8,7 +8,7 @@ When using the Ansible CLI, make sure you have all the necessary tools [installe
 
 ### Cloud Authentication
 
-See [ansible cloud authentication](AnsibleCloudAuthentication.md) when deploying to GCP with external postgres
+See [ansible cloud authentication](AnsibleCloudAuthentication.md) when deploying to Google Cloud with external postgres
 
 ### Variable Definitions (ansible-vars.yaml) File
 

docs/user/DockerUsage.md

@@ -17,7 +17,7 @@ The Docker image `viya4-deployment` will contain ansible, cloud provider cli's a
 
 ### Cloud Authentication
 
-The docker container includes the necessary cloud clis for interacting with the cloud providers. See [ansible cloud authentication](AnsibleCloudAuthentication.md) when deploying to GCP with external postgres
+The docker container includes the necessary cloud clis for interacting with the cloud providers. See [ansible cloud authentication](AnsibleCloudAuthentication.md) when deploying to Google Cloud with external postgres
 
 ### Docker Volume Mounts
 

docs/user/PostgreSQL.md

@@ -17,7 +17,7 @@ To use the IAC project to create an external PostgreSQL database cluster, refer
 
 [AWS PostgreSQL Cluster](https://github.com/sassoftware/viya4-iac-aws/blob/main/docs/CONFIG-VARS.md#postgresql-server)
 
-[GCP PostgreSQL Cluster](https://github.com/sassoftware/viya4-iac-gcp/blob/main/docs/CONFIG-VARS.md#postgres-servers)
+[Google Cloud PostgreSQL Cluster](https://github.com/sassoftware/viya4-iac-gcp/blob/main/docs/CONFIG-VARS.md#postgres-servers)
 
 ## Post Data Transfer Steps for viya4-deployment