From 5af1aa6aecfc1c21bde03ecd77291b1258c33e2e Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Thu, 17 Apr 2025 16:49:39 -0500 Subject: [PATCH 1/5] docs: move around the deploy guide pages This will hopefully this will start to make the flow easier to follow and install. --- .../{external-argocd.md => argocd.md} | 4 +- docs/deploy-guide/deploy-repo.md | 39 -------- docs/deploy-guide/getting-started.md | 88 +++++++++++++++---- docs/deploy-guide/{index.md => welcome.md} | 0 docs/index.md | 2 +- mkdocs.yml | 8 +- 6 files changed, 80 insertions(+), 61 deletions(-) rename docs/deploy-guide/{external-argocd.md => argocd.md} (93%) delete mode 100644 docs/deploy-guide/deploy-repo.md rename docs/deploy-guide/{index.md => welcome.md} (100%) diff --git a/docs/deploy-guide/external-argocd.md b/docs/deploy-guide/argocd.md similarity index 93% rename from docs/deploy-guide/external-argocd.md rename to docs/deploy-guide/argocd.md index 7134449b3..7ea08225a 100644 --- a/docs/deploy-guide/external-argocd.md +++ b/docs/deploy-guide/argocd.md @@ -1,5 +1,7 @@ -# External ArgoCD +# ArgoCD +Unlike the [Quick Start](./gitops-install.md) you will not want to run +ArgoCD, the deployment tool/engine on the same cluster hosting your workload. In most cases you will not want to run ArgoCD, the deployment tool/engine on the same cluster that is hosting your workload. The [Quick Start](./gitops-install.md) used the [apps/aio-app-of-apps.yaml][aio-app-of-apps] to initialize ArgoCD diff --git a/docs/deploy-guide/deploy-repo.md b/docs/deploy-guide/deploy-repo.md deleted file mode 100644 index a5ebd8f43..000000000 --- a/docs/deploy-guide/deploy-repo.md +++ /dev/null @@ -1,39 +0,0 @@ -# Deploy Repository - -The deployment repository will contain configuration related to your deployment. -Some of these items may be Kubernetes manifests or custom resources which will -be consumed by different tools. It is recommended that one Deploy Repository -is used per Management tier, see [Introduction](./index.md) for information -on what this is. - -The layout of this repo will be something like: - -```shell -. -├── management # (1) -│   ├── helm-configs # (2) -│   └── manifests # (3) -├── iad3-prod # (4) -│   ├── flavors -> ../flavors/prod # (5) -│   ├── helm-configs -│   └── manifests -├── iad3-staging # (6) -│   ├── flavors -> ../flavors/nonprod # (7) -│   ├── helm-configs -│   └── manifests -├── global-prod # (8) -│   ├── helm-configs -│   └── manifests -└── flavors -    ├── nonprod -    └── prod -``` - -1. This contains data which the cluster labeled as `management` will consume. -2. helm `values.yaml` files per application/component will be here for `management`. -3. Any kubernetes manifests per application/component will be here for `management`. -4. This contains data which the cluster labeled as `iad3-prod` will consume. -5. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. -6. This contains data which the cluster labeled as `iad3-staging` will consume. -7. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. Notice it is different than staging. -8. The cluster labeled as `global-prod` will have resources consumed here. diff --git a/docs/deploy-guide/getting-started.md b/docs/deploy-guide/getting-started.md index 4f1ab2fdb..cf26362ea 100644 --- a/docs/deploy-guide/getting-started.md +++ b/docs/deploy-guide/getting-started.md @@ -1,21 +1,79 @@ # Getting Started -You will need to have available a number of local utilities, -a clone of this repo and another Git repo which will be referred to -as the deploy repo. You will also need at least once Kubernetes -cluster available to you, while multiple clusters are the advisable -approach for any production or deployment at scale as the [Introduction](./index.md) -mentions. - -Embracing [GitOps][gitops] and declarative configuration, we will need to have -some items available before we begin. - -1. A Git repo that you'll be able to commit to and that you'll be able to provide -read-only credentials to the tooling to fetch data from. Something like +To get started, ensure you have the following prerequisites: + +* A clone of this repository. +* Another [Git repository,](#deploy-repository) referred to as the + [Deploy Repository](#deploy-repository). +* Access to at least one Kubernetes cluster. + +For simplicity, you can use an All-In-One deployment. However, for +production or large-scale deployments, it is recommended to use multiple +clusters, as outlined in the [System Division](./welcome.md#system-division). + +This approach embraces [GitOps][gitops] and declarative configuration. + +## Deploy Repository + +The deployment repository will contain configuration related to your deployment. +Some of these items may be Kubernetes manifests or custom resources which will +be consumed by different tools. It is recommended that one Deploy Repository +is used per Management tier, see [Introduction](./welcome.md) for information +on what this is. + +The layout of this repo will be something like: + +```shell +. +├── management # (1) +│   ├── helm-configs # (2) +│   └── manifests # (3) +├── iad3-prod # (4) +│   ├── flavors -> ../flavors/prod # (5) +│   ├── helm-configs +│   └── manifests +├── iad3-staging # (6) +│   ├── flavors -> ../flavors/nonprod # (7) +│   ├── helm-configs +│   └── manifests +├── global-prod # (8) +│   ├── helm-configs +│   └── manifests +└── flavors +    ├── nonprod +    └── prod +``` + +1. This contains data which the cluster labeled as `management` will consume. +2. helm `values.yaml` files per application/component will be here for `management`. +3. Any Kubernetes manifests per application/component will be here for `management`. +4. This contains data which the cluster labeled as `iad3-prod` will consume. +5. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. +6. This contains data which the cluster labeled as `iad3-staging` will consume. +7. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. Notice it is different than staging. +8. The cluster labeled as `global-prod` will have resources consumed here. + +### Deploy repository permissions + +To get started, you'll need a Deploy Repository that you can commit to. This means you should have write access to this repository. + +For the deployment tool, [ArgoCD](./argocd.md), you'll need to set up read-only credentials. This allows ArgoCD to fetch the necessary data without making any changes to your repository. One way to achieve this is by using [GitHub Deploy Keys][gh-deploy-keys] or similar solutions. + [GitHub Deploy Keys][gh-deploy-keys] will work. -2. A DNS zone under which you can create multiple DNS entries. You can use a service -like [sslip.io](https://sslip.io) for test purposes. -3. The ability to get SSL certificates for these domains via cert-manager. +## UnderStack Repository + +The UnderStack repository is used as a base for services installed, their +versions, common configs and containers. It will be referenced by the [ArgoCD][argocd] +Application which in turn will +reference ApplicationSets and the services, their versions and their source repositories. + +[argocd]: [gitops]: [gh-deploy-keys]: + +## DNS and SSL + +You will need a DNS zone under which you can make multiple DNS records and +utilize [cert-manager](https://cert-manager.io) to get SSL certificates for HTTPS access. +You may use something like [sslip.io](https://sslip.io) for test purposes. diff --git a/docs/deploy-guide/index.md b/docs/deploy-guide/welcome.md similarity index 100% rename from docs/deploy-guide/index.md rename to docs/deploy-guide/welcome.md diff --git a/docs/index.md b/docs/index.md index 3b628d57c..a8ab3ee58 100644 --- a/docs/index.md +++ b/docs/index.md @@ -22,6 +22,6 @@ hide: - :material-abacus:{ .xl .middle } __Getting Started__ - See our [Deploy Guide](deploy-guide/index.md) to begin with your own deployment. + See our [Deploy Guide](deploy-guide/welcome.md) to begin with your own deployment. diff --git a/mkdocs.yml b/mkdocs.yml index b042f6519..e8b39ba52 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -117,14 +117,12 @@ nav: - component-argo-workflows.md - component-understack-workflows.md - 'Deployment Guide': - - deploy-guide/index.md + - deploy-guide/welcome.md + - deploy-guide/getting-started.md - Quick Start: deploy-guide/gitops-install.md - - Full Deploy: - - deploy-guide/getting-started.md - - deploy-guide/deploy-repo.md + - deploy-guide/argocd.md - deploy-guide/auth.md - deploy-guide/extra-regions.md - - deploy-guide/external-argocd.md - deploy-guide/add-remove-app.md - deploy-guide/override-openstack-svc-config.md - 'Operator Guide': From 57d19404ac3652f79cddbbef0a9d8b23dccc7d4f Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Fri, 18 Apr 2025 17:40:04 -0500 Subject: [PATCH 2/5] docs: add more details on ArgoCD usage Adds more details on how to configure ArgoCD usage and how to define clusters. --- docs/deploy-guide/argocd.md | 156 +++++++++++++++++++++++++++++------- 1 file changed, 126 insertions(+), 30 deletions(-) diff --git a/docs/deploy-guide/argocd.md b/docs/deploy-guide/argocd.md index 7ea08225a..ec85aea14 100644 --- a/docs/deploy-guide/argocd.md +++ b/docs/deploy-guide/argocd.md @@ -1,13 +1,127 @@ # ArgoCD -Unlike the [Quick Start](./gitops-install.md) you will not want to run -ArgoCD, the deployment tool/engine on the same cluster hosting your workload. -In most cases you will not want to run ArgoCD, the deployment tool/engine on -the same cluster that is hosting your workload. The [Quick Start](./gitops-install.md) -used the [apps/aio-app-of-apps.yaml][aio-app-of-apps] to initialize ArgoCD -using the [App of Apps pattern][argo-app-of-apps]. +The deployment of all the services into your Kubernetes cluster is handled +by [ArgoCD][argocd]. The [System Division](./welcome.md#system-division) +defines the location where [ArgoCD][argocd] runs as the __Management__ cluster. +While it is possible to run ArgoCD from the same cluster that your services +will run in, it is not advisable outside of a development setup. The +approach that UnderStack uses to deploy it's services with ArgoCD is the +[App of Apps pattern][argocd-app-of-apps]. -## An existing deployment +## Deploying ArgoCD to your Management Cluster + +If you already have [ArgoCD][argocd] deployed and available to be used then you +can skip this section. + +The following command will do an initial deployment of ArgoCD that can +then be customized further. + +```bash title="installing ArgoCD" +kubectl kustomize --enable-helm https://github.com/rackerlabs/understack/bootstrap/argocd/ | kubectl apply -f - +``` + +## Configuring your Regional / Global Cluster in ArgoCD + +For [ArgoCD][argocd] to be able to deploy to your cluster, you must define your cluster in +ArgoCD. You can do this one of two ways, via the `argocd` CLI tool or via the +[Declarative Setup][argocd-decl-setup]. We are embracing GitOps so the declarative +is what we'll use. + +### Creating a Cluster Config + +```bash title="declaring a cluster config" +DEPLOY_NAME=my-site # this should match one of your top-level directories in your deploy repo +DNS_ZONE="zone.where.all.dns.entries.will.live" # all services will have DNS entries under here + +# assuming you are in the top-level of your deploy repo checkout +mkdir -p management/manifests/argocd/ + +cat << EOF > management/manifests/argocd/${DEPLOY_NAME}-cluster.yaml +apiVersion: v1 +kind: Secret +metadata: + name: ${DEPLOY_NAME}-cluster + namespace: argocd + annotations: + dns_zone: "${DNS_ZONE}" + understack.rackspace.com/env: prod + understack.rackspace.com/role: regional + labels: + argocd.argoproj.io/secret-type: cluster +type: Opaque +stringData: + name: "${DEPLOY_NAME}" + server: https://my-site-cluster:6443 + config: | + # see link below for details + +EOF +``` + +This file is not complete yet because you must configure the access to the +cluster by ArgoCD, please see [cluster config][argocd-decl-setup] for details +on how to complete this. + +There are additional annotations supported by UnderStack as well for +different configurations. + +`understack.rackspace.com/env` +: Possible values are `prod` and `dev`. If the value is set to `dev` then + various settings can be overridden so allow an easier development experience. + +`understack.rackspace.com/role` +: Possible values are `regional`, `global`, and `aio`. Which defines what + services should be deployed to this cluster based on its role. The `aio` + role stands for "All In One" and combines both `regional` and `global`. + +`dns_zone` +: The DNS zone under which all services in this cluster will have their DNS + records created. + +`uc_repo_git_url` +: URL to the UnderStack git repo to use. Can only be set for `dev` env + clusters. + +`uc_repo_ref` +: Git reference to use of the UnderStack repo. Can only be set for `dev` env + clusters. + +`uc_deploy_git_url` +: URL to the deploy git repo to use. Can only be set for `dev` env + clusters. + +`uc_deploy_ref` +: Git reference to use of the deploy repo. Can only be set for `dev` env + clusters. + +`uc_skip_components` +: string-ified JSON list of components or services from UnderStack to not + install in this cluster. + +### Deploying your Cluster Config + +Once you have the Kubernetes secret which defines your cluster config ready +you must commit it to your deploy repo and then deploy it to your ArgoCD. + +In your deploy repo you should commit your cluster config at +`management/manifests/argocd/secret-${DEPLOY_NAME}-cluster.yaml`. It is +highly advised to use a secure method to store your secrets. There are many +ways in ArgoCD to achieve this. For more details see their +[Secrets Management][argocd-secrets-mgmt] guide. + +Lastly ensure that you've added this secret to your `kustomization.yaml` with +the following: + +```bash +cd management/manifests/argocd/ +[ ! -f kustomization.yaml ] && kustomize create +kustomize edit add resource secret-${DEPLOY_NAME}-cluster.yaml +``` + +Now add these files and commit them to your deploy repo. Once this is pushed, +your ArgoCD will see the change and configure itself with your cluster. + +## Switching existing UnderStack cluster to a different ArgoCD To switch to an External ArgoCD for an existing deployment you must first disable your existing ArgoCD from deleting or updating any applications. @@ -47,27 +161,9 @@ Now we are ready to remove ArgoCD from our existing cluster. kubectl delete ns argocd ``` -You are now ready to deploy UnderStack in your external ArgoCD. - -## Deploying UnderStack in an external ArgoCD - -If you did not have UnderStack already deployed with an ArgoCD in cluster -or you followed the removal steps above, you are ready for this section. - -Firstly you must create a cluster configuration for the UnderStack -[App of Apps][app-of-apps] which can be done by treating your -setup like an [extra region](./extra-regions.md). Once you've created -your cluster config and loaded it into your ArgoCD then you can load the -UnderStack [app-of-apps] into your ArgoCD with: - -```bash -kubectl -n argocd apply -f apps/app-of-apps.yaml -``` - -If you followed the [Quick Start](./gitops-install.md), you will notice the -slightly different filename. The leading `aio` is removed which stands for -All In One. +You are now ready to deploy UnderStack in your external [ArgoCD][argocd]. -[aio-app-of-apps]: -[app-of-apps]: -[argo-app-of-apps]: +[argocd]: +[argocd-app-of-apps]: +[argocd-decl-setup]: +[argocd-secrets-mgmt]: From f707b4d4a1edbc1d18c624761c573813baebfa2d Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Fri, 18 Apr 2025 17:42:47 -0500 Subject: [PATCH 3/5] chore(argocd): simplify the ArgoCD tls snippet We don't need to go the "extra" side but use the regular tls configuration. --- bootstrap/argocd/values.yaml | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/bootstrap/argocd/values.yaml b/bootstrap/argocd/values.yaml index 39524755b..86f63f68e 100644 --- a/bootstrap/argocd/values.yaml +++ b/bootstrap/argocd/values.yaml @@ -11,13 +11,10 @@ server: ingress: enabled: true ingressClassName: nginx + tls: true annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true" nginx.ingress.kubernetes.io/backend-protocol: "HTTP" - extraTls: - - hosts: - - argocd.example.com - secretName: argocd-ingress-tls configs: params: server.insecure: true From 82ab0d88c807b6b152342ab8be3d3ac963cda5d2 Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Mon, 14 Apr 2025 09:15:32 -0500 Subject: [PATCH 4/5] docs: update some wording on the front page --- docs/index.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/docs/index.md b/docs/index.md index a8ab3ee58..0d5db66a4 100644 --- a/docs/index.md +++ b/docs/index.md @@ -11,14 +11,18 @@ hide:
- :material-cloud:{ .lg} __What is UnderStack?__ - UnderStack is an opinionated installation of OpenStack centered around Ironic - and related services to be able to provision bare metal hardware to be - consumable by genestack for the full OpenStack suite. + UnderStack is an opinionated deployment of OpenStack focused on bare metal + provisioning through Ironic and its related services. This allows for efficiently + and consistently managed hardware deployed via API-driven workflows across multiple + data centers at scale. - The requirements are a Kubernetes cluster, which these docs will contain - information about building different clusters and then a pile of bare metal - systems that can be ingested into the stack to be available to be consumed via - Openstack Ironic. + Core requirements include a pool of bare metal systems which can be controlled by + Ironic as well as switches that can be programmed by a Neutron ML2 driver and + infrastructure nodes which can host a Kubernetes cluster for the necessary services. + + The documentation covers both Kubernetes cluster deployment options and configuration + of the UnderStack components for bare metal resource management in a multi-data center + environment. - :material-abacus:{ .xl .middle } __Getting Started__ From be6c987ab26e06308b50f978f6c07d5fe99a52df Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Wed, 23 Apr 2025 17:21:39 -0500 Subject: [PATCH 5/5] docs: rename regions to sites We've gone around how a region in our existing nomenclature can encompass one or more locations so change the terminology to site from region. --- docs/deploy-guide/argocd.md | 8 +++--- .../{extra-regions.md => extra-sites.md} | 22 +++++++-------- docs/deploy-guide/getting-started.md | 4 +-- docs/deploy-guide/welcome.md | 28 +++++++++---------- mkdocs.yml | 2 +- 5 files changed, 32 insertions(+), 32 deletions(-) rename docs/deploy-guide/{extra-regions.md => extra-sites.md} (83%) diff --git a/docs/deploy-guide/argocd.md b/docs/deploy-guide/argocd.md index ec85aea14..2e338cda6 100644 --- a/docs/deploy-guide/argocd.md +++ b/docs/deploy-guide/argocd.md @@ -20,7 +20,7 @@ then be customized further. kubectl kustomize --enable-helm https://github.com/rackerlabs/understack/bootstrap/argocd/ | kubectl apply -f - ``` -## Configuring your Regional / Global Cluster in ArgoCD +## Configuring your Global and/or Site Cluster in ArgoCD For [ArgoCD][argocd] to be able to deploy to your cluster, you must define your cluster in ArgoCD. You can do this one of two ways, via the `argocd` CLI tool or via the @@ -45,7 +45,7 @@ metadata: annotations: dns_zone: "${DNS_ZONE}" understack.rackspace.com/env: prod - understack.rackspace.com/role: regional + understack.rackspace.com/role: site labels: argocd.argoproj.io/secret-type: cluster type: Opaque @@ -70,9 +70,9 @@ different configurations. various settings can be overridden so allow an easier development experience. `understack.rackspace.com/role` -: Possible values are `regional`, `global`, and `aio`. Which defines what +: Possible values are `site`, `global`, and `aio`. Which defines what services should be deployed to this cluster based on its role. The `aio` - role stands for "All In One" and combines both `regional` and `global`. + role stands for "All In One" and combines both `site` and `global`. `dns_zone` : The DNS zone under which all services in this cluster will have their DNS diff --git a/docs/deploy-guide/extra-regions.md b/docs/deploy-guide/extra-sites.md similarity index 83% rename from docs/deploy-guide/extra-regions.md rename to docs/deploy-guide/extra-sites.md index 9d81c2862..effe57d74 100644 --- a/docs/deploy-guide/extra-regions.md +++ b/docs/deploy-guide/extra-sites.md @@ -1,6 +1,6 @@ -# Extra Regions +# Extra Sites -To create extra regions the operation will be very similar to +To create extra sites the operation will be very similar to creating the initial UnderStack deployment. ## Getting the source @@ -20,13 +20,13 @@ git clone https://path/to/my/uc-deploy ## Secret Creation To avoid defining many environment variables we'll simplify by creating an -`.env` file for our deployment. In this case we'll call it `my-region.env` and +`.env` file for our deployment. In this case we'll call it `my-site.env` and place it where we've cloned understack. A complete file would look like: -```bash title="/path/to/uc-deploy/my-region.env" +```bash title="/path/to/uc-deploy/my-site.env" # this can remain as the literal value and will ensure it computes the right path UC_DEPLOY="$(cd "$(dirname ${BASH_SOURCE[0]})" && git rev-parse --show-toplevel)" -DEPLOY_NAME="my-region" +DEPLOY_NAME="my-site" DNS_ZONE=home.lab UC_DEPLOY_EMAIL="my@email" NO_ARGOCD=yes @@ -40,10 +40,10 @@ for production deployments. ```bash # from your understack checkout -./scripts/gitops-secrets-gen.sh ${UC_DEPLOY}/my-region.env +./scripts/gitops-secrets-gen.sh ${UC_DEPLOY}/my-site.env pushd "${UC_DEPLOY}" -git add my-region -git commit -m "my-region: secrets generation" +git add my-site +git commit -m "my-site: secrets generation" popd ``` @@ -56,7 +56,7 @@ add the file to the `kustomization.yaml` resources. ```bash title="generating a cluster config" ( -source ${UC_DEPLOY}/my-region.env +source ${UC_DEPLOY}/my-site.env cat << EOF > cluster-config.yaml apiVersion: v1 @@ -84,14 +84,14 @@ EOF This unfortunately does not give a working cluster config. You must determine what the correct process is for ArgoCD to authenticate and access your other -regional cluster. For information on how to do this see +siteal cluster. For information on how to do this see [ArgoCD Declarative Setup][argocd-decl-setup]. Once you've completed your cluster config you can run it through `kubeseal` with: ```bash -cat cluster-config.yaml | kubeseal -o yaml -w $UC_DEPLOY/$MAIN_DEPLOY/secrets/argocd/secret-my-region-cluster.yaml +cat cluster-config.yaml | kubeseal -o yaml -w $UC_DEPLOY/$MAIN_DEPLOY/secrets/argocd/secret-my-site-cluster.yaml ``` [gitops]: diff --git a/docs/deploy-guide/getting-started.md b/docs/deploy-guide/getting-started.md index cf26362ea..17762154e 100644 --- a/docs/deploy-guide/getting-started.md +++ b/docs/deploy-guide/getting-started.md @@ -48,9 +48,9 @@ The layout of this repo will be something like: 2. helm `values.yaml` files per application/component will be here for `management`. 3. Any Kubernetes manifests per application/component will be here for `management`. 4. This contains data which the cluster labeled as `iad3-prod` will consume. -5. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. +5. The definitions of the hardware flavors that this cluster, which later you will see maps to a site. 6. This contains data which the cluster labeled as `iad3-staging` will consume. -7. The definitions of the hardware flavors that this cluster, which later you will see maps to a region will use. Notice it is different than staging. +7. The definitions of the hardware flavors that this cluster, which later you will see maps to a site. Notice it is different than staging. 8. The cluster labeled as `global-prod` will have resources consumed here. ### Deploy repository permissions diff --git a/docs/deploy-guide/welcome.md b/docs/deploy-guide/welcome.md index 66a8e1815..23124bb1d 100644 --- a/docs/deploy-guide/welcome.md +++ b/docs/deploy-guide/welcome.md @@ -19,43 +19,43 @@ that are referred to in the documentation as: - Management - Global -- Region(s) +- Site(s) ```mermaid flowchart TD A[Management] --> B[Global]; - B[Global] --> C[Region A]; - B[Global] --> D[Region B...]; - B[Global] --> E[Region N]; + B[Global] --> C[Site A]; + B[Global] --> D[Site B...]; + B[Global] --> E[Site N]; ``` A fully functioning system only needs one _Management_ tier, one _Global_ -tier and one or more _Region_ tier(s). In this configuration, +tier and one or more _Site_ tier(s). In this configuration, the _Management_ tier is responsible for utilizing our [GitOps][gitops] tool, [ArgoCD][argocd] to deploy the expected state to all other tier. While the _Global_ tier is responsible for hosting any services that are expected to exist only once -for a whole system deployment such as the DCIM/IPAM tool. While the _Region_ +for a whole system deployment such as the DCIM/IPAM tool. While the _Site_ tiers will run the tools and services that need to live close to the actual hardware. In fact, one _Management_ tier can control multiple _Global_ tiers -and their associated _Region_ tiers. We call the grouping of the _Global_ -tier and it's associated _Region_ tiers a _partition_. An example +and their associated _Site_ tiers. We call the grouping of the _Global_ +tier and it's associated _Site_ tiers a _partition_. An example would be a staging partition and a production partition. ```mermaid flowchart TD A[Management] --> |staging| B[Global]; - B[Global] --> C[Region A]; - B[Global] --> D[Region B...]; - B[Global] --> E[Region N]; + B[Global] --> C[Site A]; + B[Global] --> D[Site B...]; + B[Global] --> E[Site N]; A[Management] --> |production| F[Global]; - F[Global] --> G[Region D]; - F[Global] --> H[Region E...]; - F[Global] --> I[Region Z]; + F[Global] --> G[Site D]; + F[Global] --> H[Site E...]; + F[Global] --> I[Site Z]; ``` [argocd]: diff --git a/mkdocs.yml b/mkdocs.yml index e8b39ba52..240536195 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -122,7 +122,7 @@ nav: - Quick Start: deploy-guide/gitops-install.md - deploy-guide/argocd.md - deploy-guide/auth.md - - deploy-guide/extra-regions.md + - deploy-guide/extra-sites.md - deploy-guide/add-remove-app.md - deploy-guide/override-openstack-svc-config.md - 'Operator Guide':