From 0363e2cb802796eea9f70df7b10c69c2f58fbb81 Mon Sep 17 00:00:00 2001 From: Alejandro Leal Date: Wed, 26 Jun 2024 15:39:19 -0400 Subject: [PATCH] Several wording and typos updates Several wording and typos updates --- blueprints/apigee/apigee-x-foundations/README.md | 2 +- blueprints/factories/README.md | 2 +- blueprints/gcve/pc-minimal/README.md | 2 +- blueprints/gke/patterns/batch/README.md | 2 +- blueprints/gke/patterns/batch/tutorial.md | 2 +- blueprints/gke/patterns/kafka/README.md | 2 +- blueprints/gke/patterns/mysql/README.md | 2 +- fast/stages/1-resman/README.md | 2 +- fast/stages/1-tenant-factory/README.md | 4 ++-- fast/stages/3-gcve/prod/README.md | 2 +- modules/__docs/20231106-factories.md | 2 +- modules/firestore/variables.tf | 2 +- modules/net-cloudnat/variables.tf | 2 +- modules/net-lb-app-ext/README.md | 2 +- modules/project-factory/README.md | 2 +- 15 files changed, 16 insertions(+), 16 deletions(-) diff --git a/blueprints/apigee/apigee-x-foundations/README.md b/blueprints/apigee/apigee-x-foundations/README.md index 665ef035..1c2ef58d 100644 --- a/blueprints/apigee/apigee-x-foundations/README.md +++ b/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. diff --git a/blueprints/factories/README.md b/blueprints/factories/README.md index c13c9da8..2d9124b1 100644 --- a/blueprints/factories/README.md +++ b/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 diff --git a/blueprints/gcve/pc-minimal/README.md b/blueprints/gcve/pc-minimal/README.md index 955e7ef6..374688c9 100644 --- a/blueprints/gcve/pc-minimal/README.md +++ b/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. diff --git a/blueprints/gke/patterns/batch/README.md b/blueprints/gke/patterns/batch/README.md index dbd92961..4b934cc5 100644 --- a/blueprints/gke/patterns/batch/README.md +++ b/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. diff --git a/blueprints/gke/patterns/batch/tutorial.md b/blueprints/gke/patterns/batch/tutorial.md index 2fab4586..08fa108e 100644 --- a/blueprints/gke/patterns/batch/tutorial.md +++ b/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 some needs to be familiar with: * ResourceFlavour diff --git a/blueprints/gke/patterns/kafka/README.md b/blueprints/gke/patterns/kafka/README.md index 1effcd8e..db9e97f0 100644 --- a/blueprints/gke/patterns/kafka/README.md +++ b/blueprints/gke/patterns/kafka/README.md @@ -15,7 +15,7 @@ -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 diff --git a/blueprints/gke/patterns/mysql/README.md b/blueprints/gke/patterns/mysql/README.md index c9bc3678..5f512e77 100644 --- a/blueprints/gke/patterns/mysql/README.md +++ b/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 diff --git a/fast/stages/1-resman/README.md b/fast/stages/1-resman/README.md index 5f220e79..3c8d148c 100644 --- a/fast/stages/1-resman/README.md +++ b/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). diff --git a/fast/stages/1-tenant-factory/README.md b/fast/stages/1-tenant-factory/README.md index 024221d8..0ca53c68 100644 --- a/fast/stages/1-tenant-factory/README.md +++ b/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. - [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: diff --git a/fast/stages/3-gcve/prod/README.md b/fast/stages/3-gcve/prod/README.md index 28a784da..79b7a5b5 100644 --- a/fast/stages/3-gcve/prod/README.md +++ b/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 diff --git a/modules/__docs/20231106-factories.md b/modules/__docs/20231106-factories.md index b9ebf451..857f9b7a 100644 --- a/modules/__docs/20231106-factories.md +++ b/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: diff --git a/modules/firestore/variables.tf b/modules/firestore/variables.tf index e51e7063..8a95d533 100644 --- a/modules/firestore/variables.tf +++ b/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." } } diff --git a/modules/net-cloudnat/variables.tf b/modules/net-cloudnat/variables.tf index b7f52164..08b4d377 100644 --- a/modules/net-cloudnat/variables.tf +++ b/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" } } diff --git a/modules/net-lb-app-ext/README.md b/modules/net-lb-app-ext/README.md index 5d95142c..cb22c262 100644 --- a/modules/net-lb-app-ext/README.md +++ b/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) diff --git a/modules/project-factory/README.md b/modules/project-factory/README.md index 4bf6760f..8d37b8dd 100644 --- a/modules/project-factory/README.md +++ b/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