Merge branch 'master' into certificate-manager

README.md

@@ -33,7 +33,7 @@ Currently available modules:
 - **process factories** - [project factory](./modules/project-factory/README.md)
 - **networking** - [DNS](./modules/dns), [DNS Response Policy](./modules/dns-response-policy/), [Cloud Endpoints](./modules/endpoints), [address reservation](./modules/net-address), [NAT](./modules/net-cloudnat), [VLAN Attachment](./modules/net-vlan-attachment/), [External Application LB](./modules/net-lb-app-ext/), [External Passthrough Network LB](./modules/net-lb-ext), [External Regional Application Load Balancer](./modules/net-lb-app-ext-regional/), [Firewall policy](./modules/net-firewall-policy), [Internal Application LB](./modules/net-lb-app-int), [Cross-region Internal Application LB](./modules/net-lb-app-int-cross-region), [Internal Passthrough Network LB](./modules/net-lb-int), [Internal Proxy Network LB](./modules/net-lb-proxy-int), [IPSec over Interconnect](./modules/net-ipsec-over-interconnect), [VPC](./modules/net-vpc), [VPC firewall](./modules/net-vpc-firewall), [VPC peering](./modules/net-vpc-peering), [VPN dynamic](./modules/net-vpn-dynamic), [HA VPN](./modules/net-vpn-ha), [VPN static](./modules/net-vpn-static), [Service Directory](./modules/service-directory), [Secure Web Proxy](./modules/net-swp)
 - **compute** - [VM/VM group](./modules/compute-vm), [MIG](./modules/compute-mig), [COS container](./modules/cloud-config-container/cos-generic-metadata/) (coredns, mysql, onprem, squid), [GKE cluster](./modules/gke-cluster-standard), [GKE hub](./modules/gke-hub), [GKE nodepool](./modules/gke-nodepool), [GCVE private cloud](./modules/gcve-private-cloud)
-- **data** - <!-- [AlloyDB instance](./modules/alloydb-instance), --> [Analytics Hub](./modules/analytics-hub), [BigQuery dataset](./modules/bigquery-dataset), [Bigtable instance](./modules/bigtable-instance), [Dataplex](./modules/dataplex), [Dataplex DataScan](./modules/dataplex-datascan/), [Cloud SQL instance](./modules/cloudsql-instance), [Spanner instance](./modules/spanner-instance), [Data Catalog Policy Tag](./modules/data-catalog-policy-tag), [Data Catalog Tag](./modules/data-catalog-tag), [Data Catalog Tag Template](./modules/data-catalog-tag-template), [Datafusion](./modules/datafusion), [Dataproc](./modules/dataproc), [GCS](./modules/gcs), [Pub/Sub](./modules/pubsub), [Dataform Repository](./modules/dataform-repository/)
+- **data** - <!-- [AlloyDB instance](./modules/alloydb-instance), --> [Analytics Hub](./modules/analytics-hub), [BigQuery dataset](./modules/bigquery-dataset), [Bigtable instance](./modules/bigtable-instance), [Dataplex](./modules/dataplex), [Dataplex DataScan](./modules/dataplex-datascan), [Cloud SQL instance](./modules/cloudsql-instance), [Spanner instance](./modules/spanner-instance), [Firestore](./modules/firestore), [Data Catalog Policy Tag](./modules/data-catalog-policy-tag), [Data Catalog Tag](./modules/data-catalog-tag), [Data Catalog Tag Template](./modules/data-catalog-tag-template), [Datafusion](./modules/datafusion), [Dataproc](./modules/dataproc), [GCS](./modules/gcs), [Pub/Sub](./modules/pubsub), [Dataform Repository](./modules/dataform-repository/)
 - **development** - [API Gateway](./modules/api-gateway), [Apigee](./modules/apigee), [Artifact Registry](./modules/artifact-registry), [Container Registry](./modules/container-registry), [Cloud Source Repository](./modules/source-repository), [Workstation cluster](./modules/workstation-cluster)
 - **security** - [Binauthz](./modules/binauthz/), [KMS](./modules/kms), [SecretManager](./modules/secret-manager), [VPC Service Control](./modules/vpc-sc)
 - **serverless** - [Cloud Function v1](./modules/cloud-function-v1), [Cloud Function v2](./modules/cloud-function-v2), [Cloud Run](./modules/cloud-run), [Cloud Run v2](./modules/cloud-run-v2)

blueprints/apigee/apigee-x-foundations/README.md

@@ -2,7 +2,7 @@
 
 This  blueprint creates all the resources necessary to set up Apigee X on Google Cloud.
 
-Apigee can be exposed to clients using Regional Internal Application Load Balancer, Global External Application Load Balancer or both. When using the Regional Internal Application Load Balancer, used self-managed certificates (incuding self-signed certificates generated in this same module). When using the Global External Application Load Balancer Google-managed certificates or self-managed certificates (including self-signed certificates generated in this same module). When using Cross-region Internal Application Load Balancer a certificate manager needs to be used and it needs to be created in the same project as Apigee.
+Apigee can be exposed to clients using Regional Internal Application Load Balancer, Global External Application Load Balancer or both. When using the Regional Internal Application Load Balancer, used self-managed certificates (including self-signed certificates generated in this same module). When using the Global External Application Load Balancer Google-managed certificates or self-managed certificates (including self-signed certificates generated in this same module). When using Cross-region Internal Application Load Balancer a certificate manager needs to be used and it needs to be created in the same project as Apigee.
 
 Find below a few examples of different Apigee architectures that can be created using this module.
 

blueprints/factories/README.md

@@ -16,7 +16,7 @@ Managing large sets of uniform resources with Terraform usually involves differe
 
 Factories are a way to simplify all above use cases, by moving repetitive resource definitions out of the Terraform codebase and into sets of files that leverage different formats.
 
-Using factories, repetive resource creation and management becomes easier
+Using factories, repetitive resource creation and management becomes easier
 
 - for humans who have no direct experience with Terraform, by exposing filesystem hierarchies and YAML-based configuration data
 - for connected systems, by accepting well know data exchange formats like JSON or CSV

blueprints/gcve/pc-minimal/README.md

@@ -3,7 +3,7 @@
 This blueprint presents an opinionated architecture to handle different Google VMware Engine deployment scenarios: from a simple single region private cloud to multi-region private clouds spread across different locations. The general idea behind this blueprint is to deploy a single project hosting one or more GCVE private clouds connected to a shared VMware Engine Network (VEN).
 Optionally this blueprint can deploy the VMWare Engine Network peerings to pre-existing VPCs.
 
-Multiple deployments of this blueprint allow the user to achieve more complex design solutions as for example GCVE private clouds deployed on different projects or connected to indipendent VMWare Engine Networks.
+Multiple deployments of this blueprint allow the user to achieve more complex design solutions as for example GCVE private clouds deployed on different projects or connected to independent VMWare Engine Networks.
 
 This blueprint is used as part of the [FAST GCVE stage](../../../fast/stages/3-gcve/) but it can also be used independently if desired.
 

blueprints/gke/patterns/batch/README.md

@@ -32,7 +32,7 @@ Once you have a cluster with Internet connectivity, create a `terraform.tfvars`
 
 Only two variables are available to control Kueue's configuration:
 - `teams_namespaces` which controls the namespaces used by different teams to run jobs.
-- `kueue_namespace` which controls the namepsace to deploy Kueue's own resources.
+- `kueue_namespace` which controls the namespace to deploy Kueue's own resources.
 
 Any other configuration can be applied by directly modifying the YAML manifests under the [manifest-templates](manifest-templates) directory.
 

blueprints/gke/patterns/batch/tutorial.md

@@ -15,7 +15,7 @@ Kueue has the following characteristics:
 * It can integrate with other job APIs.
 * Kueue refers to jobs defined with any API as Workloads, to avoid the confusion with the specific Kubernetes Job API.
 
-When working with Kueue there are a few concepts that ome needs to be familiar with:
+When working with Kueue there are a few concepts that one needs to be familiar with:
 
 * ResourceFlavour
 

blueprints/gke/patterns/kafka/README.md

@@ -15,7 +15,7 @@
 <img width="200px" src="../../../../assets/images/cloud-shell-button.png">
 </a>
 
-This blueprints shows how to a hihgly available Kakfa instance on GKE using the Strimzi operator.
+This blueprints shows how to a hihgly available Kafka instance on GKE using the Strimzi operator.
 
 ## Requirements
 

blueprints/gke/patterns/mysql/README.md

@@ -31,7 +31,7 @@ The database admin password is generated in Terraform and stored as a Kubernetes
 
 `mysql-server` Pods are spread across different zones using `topologySpreadConstraints`  with `maxSkew` of 1, `minDomains` of 3 and Pod antiAffinity preventing the Pods to run on the same host. This permits running two nodes in one zone (but on different hosts) in case of one zone failure in 3-zoned region.
 
-`mysql-router` Pods hava affinity to run in the same zones as `mysql-server` nodes and antiAffinity to run on the same host (required) or zone (preferred) as other `mysql-router` . With two instances of `mysql-router` this might result in 2 instances running in the same region
+`mysql-router` Pods have affinity to run in the same zones as `mysql-server` nodes and antiAffinity to run on the same host (required) or zone (preferred) as other `mysql-router` . With two instances of `mysql-router` this might result in 2 instances running in the same region
 
 ## Usage
 ### Prerequisites

fast/stages/1-resman/README.md

@@ -222,7 +222,7 @@ tags = {
 
 ### IAM
 
-The `folder_iam` variable can be used to manage authoritative bindings for all top-level folders. For additional control, IAM roles can be easily edited in the relevant `branch-xxx.tf` file, following the best practice outlined in the [bootstrap stage](../0-bootstrap#customizations) documentation of separating user-level and service-account level IAM policies throuth the IAM-related variables (`iam`, `iam_bindings`, `iam_bindings_additive`) of the relevant modules.
+The `folder_iam` variable can be used to manage authoritative bindings for all top-level folders. For additional control, IAM roles can be easily edited in the relevant `branch-xxx.tf` file, following the best practice outlined in the [bootstrap stage](../0-bootstrap#customizations) documentation of separating user-level and service-account level IAM policies through the IAM-related variables (`iam`, `iam_bindings`, `iam_bindings_additive`) of the relevant modules.
 
 A full reference of IAM roles managed by this stage [is available here](./IAM.md).
 

fast/stages/1-tenant-factory/README.md

@@ -2,7 +2,7 @@
 
 This optional stage implements multitenancy, where a limited number of tenants need a high degree of autonomy over their slice of the shared organization, while still being subject to a measure of central control.
 
-Typical use cases include large organizations managing a single Cloud subscription for multiple semi-indipendent entities (governments, state-wide associations), multinational groups with different local subsidiaries, or even business units who own their cloud presence while still consuming centralized resources or services.
+Typical use cases include large organizations managing a single Cloud subscription for multiple semi-independent entities (governments, state-wide associations), multinational groups with different local subsidiaries, or even business units who own their cloud presence while still consuming centralized resources or services.
 
 <!-- BEGIN TOC -->
 - [Design overview and choices](#design-overview-and-choices)
@@ -64,7 +64,7 @@ Tenants of this type can be "upgraded" at any time to FAST compatibility by simp
 
 ### FAST-compatible tenants
 
-Tenants can also be configured for FAST compatibility. This approach effectively emulates the org-level bootstrap stage, allowing tenants to indipendently bring up a complete Landing Zone in their environment using FAST.
+Tenants can also be configured for FAST compatibility. This approach effectively emulates the org-level bootstrap stage, allowing tenants to independently bring up a complete Landing Zone in their environment using FAST.
 
 The main differences compared to organization-level FAST are:
 

fast/stages/3-gcve/prod/README.md

@@ -1,6 +1,6 @@
 # GCVE Private Clouds for Production Environment
 
-This stage provides the Terraform content for the creation and management of multiple GCVE private clouds which are connected to an existing network. The network infrastructure needs to be deployed before executing this stage by executing the respective Fabric FAST stage (`2-networking-*`). This stage can be replicated for complex GCVE designs requiring a separate management of the network infrastructure (VEN) and the access domain or for other constraints which make you decide to have indipendent GCVE environments (e.g dev/prod, region or team  serparation).
+This stage provides the Terraform content for the creation and management of multiple GCVE private clouds which are connected to an existing network. The network infrastructure needs to be deployed before executing this stage by executing the respective Fabric FAST stage (`2-networking-*`). This stage can be replicated for complex GCVE designs requiring a separate management of the network infrastructure (VEN) and the access domain or for other constraints which make you decide to have independent GCVE environments (e.g dev/prod, region or team  serparation).
 
 ## Design overview and choices
 

modules/README.md

@@ -85,6 +85,7 @@ These modules are used in the examples included in this repository. If you are u
 - [Bigtable instance](./bigtable-instance)
 - [Cloud SQL instance](./cloudsql-instance)
 - [Spanner instance](./spanner-instance)
+- [Firestore](./firestore)
 - [Data Catalog Policy Tag](./data-catalog-policy-tag)
 - [Data Catalog Tag](./data-catalog-tag)
 - [Data Catalog Tag Template](./data-catalog-tag-template)

modules/__docs/20231106-factories.md

@@ -89,7 +89,7 @@ The only change for FAST factories will be moving the project factory from bluep
 
 ### File schema and filesystem organization
 
-Factory files schema must mimick and implement the variable interface for the module, including optionals and validation - which are implemented in code and checks.
+Factory files schema must mimic and implement the variable interface for the module, including optionals and validation - which are implemented in code and checks.
 
 With notable exceptions (currently only the `cidrs.yaml` file consumed by firewall factories), the following convention for files/directory is proposed:
 

modules/firestore/variables.tf

@@ -156,7 +156,7 @@ variable "fields" {
     condition = alltrue([for v1 in var.fields :
       v1.indexes == null ? true : alltrue([for v2 in coalesce(v1.indexes, []) :
     !(v2.order != null && v2.array_config != null)])])
-    error_message = "Either order or array_config should be specificied, but not both."
+    error_message = "Either order or array_config should be specified, but not both."
   }
 
 }

modules/net-cloudnat/variables.tf

@@ -79,7 +79,7 @@ variable "endpoint_types" {
       "ENDPOINT_TYPE_MANAGED_PROXY_LB",
       ])
     )
-    error_message = "Proivde one of: ENDPOINT_TYPE_VM, ENDPOINT_TYPE_SWG or ENDPOINT_TYPE_MANAGED_PROXY_LB as endpoint_types"
+    error_message = "Provide one of: ENDPOINT_TYPE_VM, ENDPOINT_TYPE_SWG or ENDPOINT_TYPE_MANAGED_PROXY_LB as endpoint_types"
   }
 }
 

modules/net-lb-app-ext/README.md

@@ -856,7 +856,7 @@ module "glb-0" {
 ```
 
 ## Deploying changes to load balancer configurations
-Load balancers consists of many resources depending on each other. The [Global external Application Load Balancer architecture for serverless apps diagram](https://cloud.google.com/load-balancing/docs/application-load-balancer#global-external) shows the structure of a Global external Application Load Balancer, but others are similiar.
+Load balancers consists of many resources depending on each other. The [Global external Application Load Balancer architecture for serverless apps diagram](https://cloud.google.com/load-balancing/docs/application-load-balancer#global-external) shows the structure of a Global external Application Load Balancer, but others are similar.
 
 ![Global external Application Load Balancer architecture for serverless apps diagram](https://cloud.google.com/static/load-balancing/images/lb-serverless-simple-ext-https.svg)
 

modules/project-factory/README.md

@@ -15,7 +15,7 @@ The factory is implemented as a thin data translation layer for the underlying m
 
 The code is meant to be executed by a high level service accounts with powerful permissions:
 
-- forlder admin permissions for the hierarchy
+- folder admin permissions for the hierarchy
 - project creation on the nodes (folder or org) where projects will be defined
 - Shared VPC connection if service project attachment is desired
 - billing cost manager permissions to manage budgets and monitoring permissions if notifications should also be managed here