Merge pull request #273 from stakater/changelog-to-main

Changelog to main

Author: msafwankarim

content/changelog.md

@@ -26,6 +26,18 @@
 - Fix a bug in sandbox creations where sandbox namespaces were not being created if there were only groups in the tenant.
 - Fix for IC controller where it would not reconcile if the cluster had too many Configmaps, making the informer cache too big to be watched.
 
+#### Pre-Upgrade Checklist
+
+Before upgrading to v1.1.0, perform the following steps:
+
+- Disable `console` in the integration config.
+- Remove the `tenant-operator-casbin-config` Configmap from the `multi-tenant-operator` namespace, if it exists.
+
+#### Post-Upgrade Checklist
+
+- Enable `console` in the integration config. [Link](./installation/openshift.md#enabling-console)
+- If the `prometheus-server` pod is failing, ensure that only one `prometheus-server` deployment exists in the `multi-tenant-operator` namespace. If multiple deployments exist, delete the older one.
+
 #### Components
 
 | Name | Tag | Image |

content/crds-api-reference/integration-config.md

@@ -202,7 +202,7 @@ Integration config will be managing the following resources required for console
 - `Prometheus` resources
 - `Opencost` resources
 - `MTO Console, Gateway, Keycloak` resources
-- `Showback` cron job
+- `Showback` cron-job
 
 Details on console GUI and showback can be found [here](../explanation/console.md)
 
@@ -346,7 +346,7 @@ This field contains roles that will be used to create default `roleBindings` for
 
 ##### Custom
 
-An array of custom roles. Similar to the `default` field, you can mention roles within this field as well. However, the custom roles also require the use of a `labelSelector` for each iteration within the array. The roles mentioned here will only apply to the namespaces that are matched by the labelSelector. If a namespace is matched by 2 different `labelSelectors`, then both roles will apply to it. Additionally, roles can be skipped within the labelSelector. These missing roles are then inherited from the `default` roles field . For example, if the following custom roles arrangement is used:
+An array of custom roles. Similar to the `default` field, you can mention roles within this field as well. However, the custom roles also require the use of a `labelSelector` for each iteration within the array. The roles mentioned here will only apply to the namespaces that are matched by the `labelSelector`. If a namespace is matched by 2 different `labelSelectors`, then both roles will apply to it. Additionally, roles can be skipped within the `labelSelector`. These missing roles are then inherited from the `default` roles field . For example, if the following custom roles arrangement is used:
 
 ```yaml
 custom:

content/crds-api-reference/template.md

@@ -100,11 +100,46 @@ resources:
     chart:
       repository:
         name: redis
+        version: 14.6.0
         repoUrl: https://charts.bitnami.com/bitnami
+        username:
+          key: username
+          name: redis-creds
+          namespace: namespace-n1
+        password:
+          key: password
+          name: redis-creds
+          namespace: namespace-n1
+    setValues:
+      - name: port
+        value: '6379'
+        forceString: false
     values: |
       redisPort: 6379
 ```
 
+A brief explanation of the fields in the Helm section:
+
+* `releaseName`: The name of the Helm release.
+* `chart`: The Helm chart details.
+    * `repository`: The Helm repository details.
+        * `name`: The name of the Helm repository.
+        * `version`: The version of the Helm chart.
+        * `repoUrl`: The URL of the Helm repository.
+    * `username`: A reference to the secret containing the username for the Helm repository in case the chart is in a private repository.
+        * `key`: The key in the secret containing the username.
+        * `name`: The name of the secret containing the username.
+        * `namespace`: The namespace of the secret containing the username.
+    * `password`: A reference to the secret containing the password for the Helm repository in case the chart is in a private repository.
+        * `key`: The key in the secret containing the password.
+        * `name`: The name of the secret containing the password.
+        * `namespace`: The namespace of the secret containing the password.
+* `setValues`: The values to set in the Helm chart.
+    * `name`: The name of the value.
+    * `value`: The value to set.
+    * `forceString`: Whether to use `--set` or `--set-string` when setting the value. Default is `false` (use `--set`).
+* `values`: The values file for the Helm chart.
+
 ### 3. Resource Mapping
 
 This approach maps secrets and configmaps from one tenant's namespace to another tenant's namespace, or within a tenant's namespace.

content/how-to-guides/azure-pricing.md

@@ -74,7 +74,7 @@ Next, create a secret for the Azure Service Principal
     When managing the service account key as a Kubernetes secret, the secret must reference the service account key JSON file, and that file must be named `service-key.json`.
 
 ```bash
-kubectl create secret generic azure-service-key -n opencost --from-file=service-key.json
+kubectl create secret generic azure-service-key -n multi-tenant-operator --from-file=service-key.json
 ```
 
 ### Update the IntegrationConfig
@@ -130,7 +130,7 @@ As well as the billing account ID, OpenCost also needs the offer ID for your sub
 The billing account and offer ID need to be passed to OpenCost in environment variables. To do this, create a secret with the following values:
 
 ```bash
-kubectl create secret generic customer-specific-pricing -n opencost --from-literal=azure-billing-account=<your billing account ID> --from-literal=azure-offer-id=<your offer ID>
+kubectl create secret generic customer-specific-pricing -n multi-tenant-operator --from-literal=azure-billing-account=<your billing account ID> --from-literal=azure-offer-id=<your offer ID>
 ```
 
 Finally, update the IntegrationConfig with the Azure pricing model:
@@ -266,7 +266,7 @@ In this guide, we have seen how to configure OpenCost to use Azure pricing model
 for example:
 
 ```bash
-kubectl create secret generic azure-pricing -n opencost --from-file=service-key.json --from-literal=azure-billing-account=<your billing account ID> --from-literal=azure-offer-id=<your offer ID> --from-file=./cloud-integration.json
+kubectl create secret generic azure-pricing -n multi-tenant-operator --from-file=service-key.json --from-literal=azure-billing-account=<your billing account ID> --from-literal=azure-offer-id=<your offer ID> --from-file=./cloud-integration.json
 ```
 
 Update the IntegrationConfig to use the secret:

content/how-to-guides/extend-default-roles.md

@@ -21,4 +21,5 @@ rules:
       - groups
 ```
 
-> Note: You can learn more about `aggregated-cluster-roles` [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
+!!! note
+    You can learn more about `aggregated-cluster-roles` [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)

content/installation/azure-aks.md

@@ -220,7 +220,7 @@ cert-manager-webhook-757c9d4bb7-wd9g8      1/1     Running   0          7m18s
 
 Helm will be used to install MTO as it is the only available way of installing it on Kubernetes Clusters.
 
-Use helm install command to install MTO helm chart. Here, `bypassedGroups` has to be set as `system:masters` as it is used by `masterclient` of AKS and `<mto-admins-id>`as it is used by the `test-admin-user`:
+Use helm install command to install MTO helm chart. Here, `bypassedGroups` has to be set as `system:masters` as it is used by `masterclient` of AKS and `<mto-admins-id>`as it is used by `test-admin-user`:
 
 ```terminal
 helm install tenant-operator oci://ghcr.io/stakater/public/charts/multi-tenant-operator --version 0.12.62 --namespace multi-tenant-operator --create-namespace --set bypassedGroups='system:masters\,<mto-admins-id>'
@@ -362,7 +362,7 @@ Notice that MTO has created two namespaces under each tenant.
 
 ### AppDev group
 
-AppDev is one of the previously created groups, its scope is limited to Tenant A namespaces as we mentioned its group ID in Tenant A. Start by clearing token of test-admin-user:
+AppDev is one of the previously created groups, its scope is limited to Tenant A namespaces as we mentioned its group ID in Tenant A. Start by clearing token of `test-admin-user`:
 
 ```terminal
 kubelogin remove-tokens