Merge branch 'main' into update-ld-images

.github/md_config.json

@@ -1,4 +1,5 @@
 {
+  "aliveStatusCodes": [429, 200, 520], 
   "ignorePatterns": [
     {
       "pattern": "^(https://stakater).+"

.gitignore

@@ -17,3 +17,6 @@ coverage/
 # Typescript build info
 *.tsbuildinfo
 node_modules
+
+# Build files
+site/

docs/content/sre/multi-tenant-operator/changelog.md

@@ -1,26 +1,52 @@
 # Changelog
 
+## v0.8.x
+
+**v0.8.1**
+
+- fix: Updated release pipelines
+
+**v0.8.0**
+
+- feat: Allow custom roles for each tenant via label selector, more details in [custom roles document](./usecases/custom-roles.md)
+  - Roles mapping is a required field in [MTO's IntegrationConfig](./integration-config.md). By default, it will always be filled with OpenShift's admin/edit/view roles
+  - Ensure that mentioned roles exist within the cluster
+  - Remove coupling with OpenShift's built-in admin/edit/view roles
+- feat: Removed coupling of ResourceSupervisor and Tenant resources
+  - Added list of namespaces to hibernate within the ResourceSupervisor resource
+  - Ensured that the same namespace cannot be added to two different Resource Supervisors
+  - Moved ResourceSupervisor into a separate pod
+  - Improved logs
+- fix: Remove bug from tenant's common and specific metadata
+- fix: Add missing field to Tenant's conversion webhook
+- fix: Fix panic in ResourceSupervisor sleep functionality due to sending on closed channel
+- chore: Update dependencies
+
 ## v0.7.x
 
+**v0.7.4**
+
+- maintain: Automate certification of new MTO releases on RedHat's Operator Hub
+
 **v0.7.3**
 
-- feat: Updated Tenant CR to provide Tenant level AppProject permissions.
+- feat: Updated Tenant CR to provide Tenant level AppProject permissions
 
 **v0.7.2**
 
-- feat: Add support to map secrets/configmaps from one namespace to other namespaces using TI. Secrets/configmaps will only be mapped if their namespaces belong to same Tenant.
+- feat: Add support to map secrets/configmaps from one namespace to other namespaces using TI. Secrets/configmaps will only be mapped if their namespaces belong to same Tenant
 
 **v0.7.1**
 
-- feat: Add option to keep AppProjects created by Multi Tenant Operator in case Tenant is deleted. By default, AppProjects get deleted.
-- fix: Status now updates after namespaces are created.
+- feat: Add option to keep AppProjects created by Multi Tenant Operator in case Tenant is deleted. By default, AppProjects get deleted
+- fix: Status now updates after namespaces are created
 - maintain: Changes to Helm chart's default behaviour
 
 **v0.7.0**
 
-- feat: Add support to map secrets/configmaps from one namespace to other namespaces using TGI. Resources can be mapped from one Tenant's namespaces to some other Tenant's namespaces.
+- feat: Add support to map secrets/configmaps from one namespace to other namespaces using TGI. Resources can be mapped from one Tenant's namespaces to some other Tenant's namespaces
 - feat: Allow creation of sandboxes that are private to the user
-- feat: Allow creation of namespaces without tenant prefix from within tenant spec.
+- feat: Allow creation of namespaces without tenant prefix from within tenant spec
 - fix: Webhook changes will now be updated without manual intervention
 - maintain: Updated Tenant CR version from v1beta1 to v1beta2. Conversion webhook is added to facilitate transition to new version
   - see [Tenant spec](./customresources.md#_2-tenant) for updated spec
@@ -173,15 +199,12 @@
 - fix: Added missing check for users in a tenant owner's groups in namespace validation webhook
 - fix: General enhancements and improvements
 
-::: warning Known Issues:
-
-- `caBundle` field in validation webhooks is not being populated for newly added webhooks. A temporary fix is to edit the validation webhook configuration manifest without the `caBundle` field added in any webhook, so OpenShift can add it to all fields simultaneously.
-    - Edit the `ValidatingWebhookConfiguration` `stakater-tenant-operator-validating-webhook-configuration` by removing all the `caBundle` fields of all webhooks.
-    - Save the manifest.
-    - Verify that all `caBundle` fields have been populated.
-    - Restart Tenant-Operator pods.
-
-:::
+> ⚠️ Known Issues
+- `caBundle` field in validation webhooks is not being populated for newly added webhooks. A temporary fix is to edit the validation webhook configuration manifest without the `caBundle` field added in any webhook, so OpenShift can add it to all fields simultaneously
+    - Edit the `ValidatingWebhookConfiguration` `stakater-tenant-operator-validating-webhook-configuration` by removing all the `caBundle` fields of all webhooks
+    - Save the manifest
+    - Verify that all `caBundle` fields have been populated
+    - Restart Tenant-Operator pods
 
 **v0.3.21**
 
@@ -197,13 +220,10 @@
 - fix: Fixed config not being updated in namespace webhook when Integration Config is updated
 - fix: Fixed a crash that occurred in case of ArgoCD in Integration Config was not set during deletion of Tenant resource
 
-::: warning Note:
-
-ApiVersion `v1alpha1` of Tenant and Quota custom resources has been deprecated and is scheduled to be removed in the future. The following links contain the updated structure of both resources
-
-- [Quota v1beta1](./customresources.md#_1-quota)
-- [Tenant v1beta1](./customresources.md#_2-tenant)
-:::
+> ⚠️ ApiVersion `v1alpha1` of Tenant and Quota custom resources has been deprecated and is scheduled to be removed in the future. The following links contain the updated structure of both resources
+>
+> - [Quota v1beta1](./customresources.md#_1-quota)
+> - [Tenant v1beta1](./customresources.md#_2-tenant)
 
 **v0.3.18**
 

docs/content/sre/multi-tenant-operator/customresources.md

@@ -191,11 +191,8 @@ spec:
   * `Template` resources are created in those `namespaces` which belong to a `tenant` and contain `matching labels`.
   * `Template` resources are created in all `namespaces` of a `tenant` if `selector` field is empty.
 
-::: warning Note:
 
-If same label or annotation key is being applied using different methods provided, then the highest precedence will be given to `specificMetadata` followed by `commonMetadata` and in the end would be the ones applied from `openshift.project.labels`/`openshift.project.annotations` in `IntegrationConfig`
-
-:::
+> ⚠️ If same label or annotation key is being applied using different methods provided, then the highest precedence will be given to `specificMetadata` followed by `commonMetadata` and in the end would be the ones applied from `openshift.project.labels`/`openshift.project.annotations` in `IntegrationConfig`
 
 ## 3. Template
 
@@ -351,14 +348,18 @@ spec:
   hibernation:
     sleepSchedule: 23 * * * *
     wakeSchedule: 26 * * * *
-  tenant: alpha
+  namespaces:
+    - stage
+    - dev
 status:
   currentStatus: running
   nextReconcileTime: '2022-07-07T11:23:00Z'
 ```
 
 The `ResourceSupervisor` is a resource created by MTO in case the [Hibernation](./hibernation.md) feature is enabled. The Resource manages the sleep/wake schedule of the namespaces owned by the tenant, and manages the previous state of any sleeping application. Currently, only StatefulSets and Deployments are put to sleep. Additionally, ArgoCD AppProjects that belong to the tenant have a `deny` SyncWindow added to them.
 
+The `ResourceSupervisor` can be created both via the `Tenant` or manually. For more details, check some of its [use cases](./usecases/hibernation.md)
+
 ## Namespace
 
 ```yaml

docs/content/sre/multi-tenant-operator/installation.md

@@ -42,11 +42,8 @@ This document contains instructions on installing and configuring Multi Tenant O
 
 ![image](./images/to_installed_successful.png)
 
-::: warning Note:
 
-* MTO will be installed in `multi-tenant-operator` namespace.
-
-:::
+> Note: MTO will be installed in `multi-tenant-operator` namespace.
 
 ### Configuring IntegrationConfig
 
@@ -76,11 +73,7 @@ spec:
 
 For more details and configurations check out [IntegrationConfig](./integration-config.md).
 
-::: warning Note:
-
-* A default IntegrationConfig with the name `tenant-operator-config` will be present in MTO's installed namespace
-
-:::
+> ⚠️ A default IntegrationConfig with the name `tenant-operator-config` will be present in MTO's installed namespace
 
 ### Uninstall
 
@@ -173,11 +166,7 @@ spec:
 
 For more details and configurations check out [IntegrationConfig](./integration-config.md).
 
-::: warning Note:
-
-* A default IntegrationConfig with the name `tenant-operator-config` will be present in MTO's installed namespace
-
-:::
+> ⚠️ A default IntegrationConfig with the name `tenant-operator-config` will be present in MTO's installed namespace
 
 ### Uninstall
 
@@ -323,4 +312,4 @@ A default `IntegrationConfig` is installed with MTO, which can be found in `stak
 
 * If MTO is deployed in a newly created namespace, restart its pod once so MTO can retrieve webhook-server-cert provided by OpenShift (if the pod is started before the secret was made).
 * For more details on how to use MTO please refer [use-cases](./../multi-tenant-operator/usecases/quota.md).
-* For more details on how to extend your MTO manager ClusterRole please refer [use-cases](./../multi-tenant-operator/usecases/manager-clusterrole.md).
+* For more details on how to extend your MTO manager ClusterRole please refer [use-cases](./../multi-tenant-operator/usecases/manager-clusterrole.md).

docs/content/sre/multi-tenant-operator/integration-config.md

@@ -102,9 +102,8 @@ Following are the different components that can be used to configure multi-tenan
 
 TenantRoles are required within the IntegrationConfig, as they are used for defining what roles will be applied to each Tenant namespace. The field allows optional custom roles, that are then used to create RoleBindings for namespaces that match a labelSelector.
 
-::: warning Note:
 
-If you do not configure roles in any way, then the default OpenShift roles of `owner`, `edit`, and `view` will apply to Tenant members. Their details can be found [here](./tenant-roles.md)
+> ⚠️ If you do not configure roles in any way, then the default OpenShift roles of `owner`, `edit`, and `view` will apply to Tenant members. Their details can be found [here](./tenant-roles.md)
 
 ```yaml
 tenantRoles:
@@ -279,8 +278,7 @@ namespaceAccessPolicy:
         - [email protected]
 ```
 
-#### :memo: Note
-If you want to use a more complex regex pattern (for the `openshift.privilegedNamespaces` or `openshift.privilegedServiceAccounts` field), it is recommended that you test the regex pattern first -  either locally or using a platform such as https://regex101.com/.
+> ⚠️ If you want to use a more complex regex pattern (for the `openshift.privilegedNamespaces` or `openshift.privilegedServiceAccounts` field), it is recommended that you test the regex pattern first -  either locally or using a platform such as https://regex101.com/.
 
 ## ArgoCD
 

docs/content/sre/multi-tenant-operator/tenant-roles.md

@@ -1,8 +1,5 @@
-::: warning Note
 
-After adding support for custom roles within MTO, this page is only applicable if you use OpenShift and its default `owner`, `edit`, and `view` roles. For more details, see the [IntegrationConfig spec](./integration-config.md)
-
-:::
+> After adding support for custom roles within MTO, this page is only applicable if you use OpenShift and its default `owner`, `edit`, and `view` roles. For more details, see the [IntegrationConfig spec](./integration-config.md)
 
 # Tenant Member Roles
 

docs/content/sre/multi-tenant-operator/usecases/hibernation.md

@@ -55,6 +55,10 @@ spec:
   hibernation:
     sleepSchedule: 0 20 * * 1-5
     wakeSchedule: 0 8 * * 1-5
+  namespaces:
+    - build
+    - stage
+    - dev
 status:
   currentStatus: running
   nextReconcileTime: '2022-10-12T20:00:00Z'
@@ -76,6 +80,10 @@ spec:
   hibernation:
     sleepSchedule: 0 20 * * 1-5
     wakeSchedule: 0 8 * * 1-5
+  namespaces:
+    - build
+    - stage
+    - dev
 status:
   currentStatus: sleeping
   nextReconcileTime: '2022-10-13T08:00:00Z'
@@ -106,6 +114,9 @@ spec:
   hibernation:
     sleepSchedule: 0 20 * * 1-5
     wakeSchedule: 0 8 * * 1-5
+  namespaces:
+    - stage
+    - dev
 status:
   currentStatus: sleeping
   nextReconcileTime: '2022-10-13T08:00:00Z'
@@ -115,9 +126,10 @@ status:
       name: example
       replicas: 3
 ```
+
 ## Hibernating namespaces and/or ArgoCD Applications with ResourceSupervisor
 
-Bill, the cluster administrator, wants to hibernate a collection of namespaces and AppProjects belonging to multiple different tenants. He can do so by creating a ResourceSupervisor manually, and specifying in its spec the hibernation schedule, and the namespaces and ArgoCD Applications that need to be hibernated as per the mentioned schedule. 
+Bill, the cluster administrator, wants to hibernate a collection of namespaces and AppProjects belonging to multiple different tenants. He can do so by creating a ResourceSupervisor manually, and specifying in its spec the hibernation schedule, and the namespaces and ArgoCD Applications that need to be hibernated as per the mentioned schedule.
 Bill can also use the same method to hibernate some namespaces and ArgoCD Applications that do not belong to any tenant on his cluster.
 
 The example given below will hibernate the ArgoCD Applications in the 'test-app-project' AppProject; and it will also hibernate the 'ns2' and 'ns4' namespaces.
@@ -146,4 +158,4 @@ status:
       kind: Deployment
       name: test-deployment
       replicas: 3
-```
+```

docs/content/sre/multi-tenant-operator/usecases/namespace.md

@@ -11,10 +11,7 @@ metadata:
     stakater.com/tenant: bluesky
 ```
 
-::: warning Note:
-
-Anna is required to add the tenant label `stakater.com/tenant: bluesky` which contains the name of her tenant `bluesky`, while creating the namespace. If this label is not added or if Anna does not belong to the `bluesky` tenant, then Multi Tenant Operator will not allow the creation of that namespace.
-:::
+> ⚠️ Anna is required to add the tenant label `stakater.com/tenant: bluesky` which contains the name of her tenant `bluesky`, while creating the namespace. If this label is not added or if Anna does not belong to the `bluesky` tenant, then Multi Tenant Operator will not allow the creation of that namespace.
 
 When Anna creates the namespace, MTO assigns Anna and other tenant members the roles based on their user types, such as a tenant owner getting the OpenShift `admin` role for that namespace.
 

docs/content/sre/multi-tenant-operator/usecases/volume-limits.md

@@ -34,7 +34,7 @@ spec:
 EOF
 ```
 
-Now, the combined storage used by all tenant namespaces will not exceed `50Gi`. 
+Now, the combined storage used by all tenant namespaces will not exceed `50Gi`.
 
 ### Adding StorageClass Restrictions for Tenant
 
@@ -71,12 +71,8 @@ spec:
 EOF
 ```
 
-Now, the combined storage provisioned from StorageClass `stakater` used by all tenant namespaces will not exceed `20Gi`. 
+Now, the combined storage provisioned from StorageClass `stakater` used by all tenant namespaces will not exceed `20Gi`.
 
-::: warning Note:
-The `20Gi` limit will only be applied to StorageClass `stakater`. If a tenant member creates a PVC with some other StorageClass, he will not be restricted.
-:::
+> ⚠️ The `20Gi` limit will only be applied to StorageClass `stakater`. If a tenant member creates a PVC with some other StorageClass, he will not be restricted.
 
-::: tip
-More details about `Resource Quota` can be found [here](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
-:::
+> tip: More details about `Resource Quota` can be found [here](https://kubernetes.io/docs/concepts/policy/resource-quotas/)