Gh4 fix change gt lt structure (#5)

* renamed <x-fleet-id> directories

* namespace renamed

* variables changed to _X-FLEET-ID

* additional namespace name change to _NAMESPACE

* spelling correction

* spelling correction and X-FLEET-ID

* spelling update

* x-fleet-id updates

README.md

@@ -1,9 +1,9 @@
 # tier34 repo
 
-A repository that includes YAML manifests. Manifests can define GCP resources in `config connector` format or the Kubernetes components and resources. Refer to this repo for additionnal information. TODO: add link
+A repository that includes YAML manifests. Manifests can define GCP resources in `config connector` format or the Kubernetes components and resources. Refer to this repo for additional information. TODO: add link
 
 - The `/*/configcontroller` folder is where GCP resources are defined using their `config connector` schema.
-- The `/*/kubernetes/<x-fleet-id>/**/<namespace>` folder is where resources that have to be provisionned in a kubernetes `namespace` are defined. The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
+- The `/*/kubernetes/_X-FLEET-ID/**/_NAMESPACE` folder is where resources that have to be provisioned in a kubernetes `namespace` are defined. The `_X-FLEET-ID` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
 
   The GKE clusters are joined to an [Anthos Fleet](https://cloud.google.com/anthos/fleet-management/docs). This enables Anthos policy controller, Anthos config management and Anthos service mesh(future).
 
@@ -37,10 +37,10 @@ The `/tier3` folder is where security and networking resources that enables the
 ## tier4
 
 - The `/tier4/architecture` folder is where you can store **design** documents describing your application. These will be reviewed by the security admins and the platform admins when you will submit a pull request affecting `tier3`.
-- The `/tier4/configcontroller` folder is where application resources that have to be provisionned in the GCP project are defined.
-- The `/tier4/kubernetes/<x-fleet-id>/**/<namespace>` folder is where resources that have to be provisionned in a kubernetes namespace are defined.
+- The `/tier4/configcontroller` folder is where application resources that have to be provisioned in the GCP project are defined.
+- The `/tier4/kubernetes/_X-FLEET-ID/**/_NAMESPACE` folder is where resources that have to be provisioned in a kubernetes namespace are defined.
 
->> Replace `<x-fleet-id>` with fleet-id and character "x" as the environment code because this folder will contain the configuration for all environments.
+>> Replace `_X-FLEET-ID` with fleet-id and character "x" as the environment code because this folder will contain the configuration for all environments.
 
 ### Contributing
 

csync/tier3/kubernetes/<x-fleet-id>/source-base/root-sync-git/README.md → csync/tier3/kubernetes/_X-FLEET-ID/source-base/root-sync-git/README.md

@@ -1,27 +1,27 @@
-# Introduction 
-A package to create a [Config Sync](https://cloud.google.com/anthos-config-management/docs/config-sync-overview) RepoSync object for an Azure DevOps git repo.
-
-# Requirements
-The `git-creds` secret must already be created in the KCC cluster:
-```bash
-kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my azdo organization>' --from-literal=token='<my code read token>'
-```
-### GitHub Credentials
-If you are using GitHub as a config sync repository the configuration of the kubernetes secret is done in the same manner. Please note you cannot have the @github.com appended to the end of your token as you see in a local .git-credentials file. GitHub recommends creating a machine account with limited repository access over a PAT. 
-
-```bash
-kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my github username | machine account>' --from-literal=token='<token>'
-```
-
-> The revision (version) does not appear to work for annotated tags, like the ones created from the Azure DevOps UI.  When running `git rev-parse 0.0.0` on those, a different commit is returned and Config Sync throws an error.  Tags should be created in a way similar to this (ideally by a pipeline):
-```bash
-git tag 0.0.0
-git push origin --tags
-```
-
-# Usage
-Get the package by running the following, optionally setting the revision and destination folder:
-
-`kpt pkg get https://PKG_URL@<REVISION> <DESTINATION_FOLDER>`
-
+# Introduction 
+A package to create a [Config Sync](https://cloud.google.com/anthos-config-management/docs/config-sync-overview) RepoSync object for an Azure DevOps git repo.
+
+# Requirements
+The `git-creds` secret must already be created in the KCC cluster:
+```bash
+kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my azdo organization>' --from-literal=token='<my code read token>'
+```
+### GitHub Credentials
+If you are using GitHub as a config sync repository the configuration of the kubernetes secret is done in the same manner. Please note you cannot have the @github.com appended to the end of your token as you see in a local .git-credentials file. GitHub recommends creating a machine account with limited repository access over a PAT. 
+
+```bash
+kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my github username | machine account>' --from-literal=token='<token>'
+```
+
+> The revision (version) does not appear to work for annotated tags, like the ones created from the Azure DevOps UI.  When running `git rev-parse 0.0.0` on those, a different commit is returned and Config Sync throws an error.  Tags should be created in a way similar to this (ideally by a pipeline):
+```bash
+git tag 0.0.0
+git push origin --tags
+```
+
+# Usage
+Get the package by running the following, optionally setting the revision and destination folder:
+
+`kpt pkg get https://PKG_URL@<REVISION> <DESTINATION_FOLDER>`
+
 Follow instructions inside the `setters-version.yaml` and `setters.yaml` to customize for your environment. Examples have been provided for GitHub. Comment out the AZDO sections and comment in the GitHub appropriately.

csync/tier3/kubernetes/<x-fleet-id>/source-base/root-sync-git/root-sync-git.yaml → csync/tier3/kubernetes/_X-FLEET-ID/source-base/root-sync-git/root-sync-git.yaml

@@ -15,7 +15,7 @@ spec:
   git:
     repo: https://[email protected]/AZDO-ORG/AZDO-PROJECT/_git/REPO-NAME # kpt-set: ${repo-url}
     branch: main # kpt-set: ${repo-branch}
-    dir: tier3/kubernetes/<x-fleet-id>/deploy/<env> # kpt-set: ${repo-dir}
+    dir: tier3/kubernetes/_X-FLEET-ID/deploy/<env> # kpt-set: ${repo-dir}
     revision: HEAD # kpt-set: ${version}
     auth: token
     secretRef:

csync/tier3/kubernetes/<x-fleet-id>/source-customization/prod/root-sync-git/setters.yaml → csync/tier3/kubernetes/_X-FLEET-ID/source-base/root-sync-git/setters.yaml

@@ -14,4 +14,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier3/kubernetes/<x-fleet-id>/deploy/prod
+  repo-dir: tier3/kubernetes/_X-FLEET-ID/deploy/<env>

csync/tier3/kubernetes/<x-fleet-id>/source-customization/dev/root-sync-git/setters.yaml → csync/tier3/kubernetes/_X-FLEET-ID/source-customization/dev/root-sync-git/setters.yaml

@@ -14,4 +14,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier3/kubernetes/<x-fleet-id>/deploy/dev
+  repo-dir: tier3/kubernetes/_X-FLEET-ID/deploy/dev

csync/tier3/kubernetes/<x-fleet-id>/source-customization/preprod/root-sync-git/setters.yaml → csync/tier3/kubernetes/_X-FLEET-ID/source-customization/preprod/root-sync-git/setters.yaml

@@ -14,4 +14,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier3/kubernetes/<x-fleet-id>/deploy/preprod
+  repo-dir: tier3/kubernetes/_X-FLEET-ID/deploy/preprod

csync/tier3/kubernetes/<x-fleet-id>/source-base/root-sync-git/setters.yaml → csync/tier3/kubernetes/_X-FLEET-ID/source-customization/prod/root-sync-git/setters.yaml

@@ -14,4 +14,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier3/kubernetes/<x-fleet-id>/deploy/<env>
+  repo-dir: tier3/kubernetes/_X-FLEET-ID/deploy/prod

csync/tier4/kubernetes/<x-fleet-id>/source-base/<namespace>/repo-sync-git/README.md → csync/tier4/kubernetes/_X-FLEET-ID/source-base/_NAMESPACE/repo-sync-git/README.md

@@ -1,27 +1,27 @@
-# Introduction 
-A package to create a [Config Sync](https://cloud.google.com/anthos-config-management/docs/config-sync-overview) RepoSync object for an Azure DevOps git repo.
-
-# Requirements
-The `git-creds` secret must already be created in the KCC cluster:
-```bash
-kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my azdo organization>' --from-literal=token='<my code read token>'
-```
-### GitHub Credentials
-If you are using GitHub as a config sync repository the configuration of the kubernetes secret is done in the same manner. Please note you cannot have the @github.com appended to the end of your token as you see in a local .git-credentials file. GitHub recommends creating a machine account with limited repository access over a PAT. 
-
-```bash
-kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my github username | machine account>' --from-literal=token='<token>'
-```
-
-> The revision (version) does not appear to work for annotated tags, like the ones created from the Azure DevOps UI.  When running `git rev-parse 0.0.0` on those, a different commit is returned and Config Sync throws an error.  Tags should be created in a way similar to this (ideally by a pipeline):
-```bash
-git tag 0.0.0
-git push origin --tags
-```
-
-# Usage
-Get the package by running the following, optionally setting the revision and destination folder:
-
-`kpt pkg get https://PKG_URL@<REVISION> <DESTINATION_FOLDER>`
-
+# Introduction 
+A package to create a [Config Sync](https://cloud.google.com/anthos-config-management/docs/config-sync-overview) RepoSync object for an Azure DevOps git repo.
+
+# Requirements
+The `git-creds` secret must already be created in the KCC cluster:
+```bash
+kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my azdo organization>' --from-literal=token='<my code read token>'
+```
+### GitHub Credentials
+If you are using GitHub as a config sync repository the configuration of the kubernetes secret is done in the same manner. Please note you cannot have the @github.com appended to the end of your token as you see in a local .git-credentials file. GitHub recommends creating a machine account with limited repository access over a PAT. 
+
+```bash
+kubectl create secret generic git-creds --namespace="config-management-system" --from-literal=username='<my github username | machine account>' --from-literal=token='<token>'
+```
+
+> The revision (version) does not appear to work for annotated tags, like the ones created from the Azure DevOps UI.  When running `git rev-parse 0.0.0` on those, a different commit is returned and Config Sync throws an error.  Tags should be created in a way similar to this (ideally by a pipeline):
+```bash
+git tag 0.0.0
+git push origin --tags
+```
+
+# Usage
+Get the package by running the following, optionally setting the revision and destination folder:
+
+`kpt pkg get https://PKG_URL@<REVISION> <DESTINATION_FOLDER>`
+
 Follow instructions inside the `setters-version.yaml` and `setters.yaml` to customize for your environment. Examples have been provided for GitHub. Comment out the AZDO sections and comment in the GitHub appropriately.

csync/tier4/kubernetes/<x-fleet-id>/source-base/<namespace>/repo-sync-git/repo-sync-git.yaml → csync/tier4/kubernetes/_X-FLEET-ID/source-base/_NAMESPACE/repo-sync-git/repo-sync-git.yaml

@@ -17,7 +17,7 @@ spec:
     repo: https://[email protected]/AZDO-ORG/AZDO-PROJECT/_git/REPO-NAME # kpt-set: ${repo-url}
     branch: main # kpt-set: ${repo-branch}
     # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-    dir: tier4/kubernetes/<x-fleet-id>/namespace/deploy/<env>/<namespace> # kpt-set: ${repo-dir}
+    dir: tier4/kubernetes/_X-FLEET-ID/namespace/deploy/<env>/<namespace> # kpt-set: ${repo-dir}
     revision: 0.0.0 # kpt-set: ${version}
     auth: token
     secretRef:

csync/tier4/kubernetes/<x-fleet-id>/source-base/<namespace>/repo-sync-git/setters.yaml → csync/tier4/kubernetes/_X-FLEET-ID/source-base/_NAMESPACE/repo-sync-git/setters.yaml

@@ -11,4 +11,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier4/kubernetes/<x-fleet-id>/deploy/<env>/<namespace>
+  repo-dir: tier4/kubernetes/_X-FLEET-ID/deploy/<env>/_NAMESPACE

csync/tier4/kubernetes/<x-fleet-id>/source-customization/dev/<namespace>/repo-sync-git/setters.yaml → csync/tier4/kubernetes/_X-FLEET-ID/source-customization/dev/_NAMESPACE/repo-sync-git/setters.yaml

@@ -11,4 +11,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier4/kubernetes/<x-fleet-id>/deploy/dev/<namespace>
+  repo-dir: tier4/kubernetes/_X-FLEET-ID/deploy/dev/_NAMESPACE

csync/tier4/kubernetes/<x-fleet-id>/source-customization/preprod/<namespace>/repo-sync-git/setters.yaml → csync/tier4/kubernetes/_X-FLEET-ID/source-customization/preprod/_NAMESPACE/repo-sync-git/setters.yaml

@@ -11,4 +11,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier4/kubernetes/<x-fleet-id>/deploy/preprod/<namespace>
+  repo-dir: tier4/kubernetes/_X-FLEET-ID/deploy/preprod/_NAMESPACE

csync/tier4/kubernetes/<x-fleet-id>/source-customization/prod/<namespace>/repo-sync-git/setters.yaml → csync/tier4/kubernetes/_X-FLEET-ID/source-customization/prod/_NAMESPACE/repo-sync-git/setters.yaml

@@ -11,4 +11,4 @@ data:
   # repo-url: https://github.com/GITHUB-ORG/REPO-NAME # Alternate, GitHub
   repo-branch: main
   # The `x-fleet-id` is the GCP project-id where the kubernetes clusters are deployed with character "x" as the environment code because this folder will contain the configuration for all environments.
-  repo-dir: tier4/kubernetes/<x-fleet-id>/deploy/prod/<namespace>
+  repo-dir: tier4/kubernetes/_X-FLEET-ID/deploy/prod/_NAMESPACE