wip

Author: gathomas

README.md

@@ -1,3 +1,7 @@
 # Managed Tenants SRE Docs
 
-Documentation for Managed Tenants SRE at Red Hat
+Documentation for Managed Tenants SRE at Red Hat.
+
+## Run Locally
+
+`hugo server`

content/en/_index.md

@@ -26,15 +26,12 @@ weight: 10
     class="mt-5 animate__animated animate__slideInLeft animate__fast animate__delay-1s">
     <h1>Developers</h1>
     <p>
-      Automation Tooling, CI/CD, SDKs, reference and example projects, guides and API documentation for developers working on managed services and their dependencies.
+      Addons, Automation Tooling, CI/CD, SDKs, reference and example projects, guides and API documentation for developers working on managed services and their dependencies.
     </p>
+    <a class="btn btn-lg btn-primary mr-3 mb-4" href="{{< relref "/docs/creating-addons" >}}">Get Started</a>
     <a class="btn btn-lg btn-outline-light mr-3 mb-4" href="https://sdk.operatorframework.io/docs/">Operator SDK</a>
     <a class="btn btn-lg btn-outline-light mr-3 mb-4" href="https://source.redhat.com/groups/public/openshiftplatformsre">Platform SRE</a>
   </div>
 
-  <div class="mt-5 animate__animated animate__slideInLeft animate__fast animate__delay-2s">
-    <h1>Vendor Integrators</h1>
-    <p>Integrating and offering Red Hat external services within managed OpenShift.</p>
-  </div>
 </div>
 {{< /blocks/section >}}

content/en/docs/addons-flow/architecture.md

@@ -3,8 +3,6 @@ title: "Addons Flow Architecture"
 date: 2022-12-15T00:53:51+01:00
 ---
 
-# Add-Ons Flow Architecture
-
 Add-Ons are Operators. As such, Add-Ons are installed using typical Operator
 objects, like `Subscription`, `OperatorGroup` and `CatalogSource`.
 
@@ -29,12 +27,12 @@ the corresponding bundles directories (`managed-tenants-bundles/addons/<addon_na
 The Managed Tenants CI is in charge of processing the input and deploying all
 the artifacts. This image shows the data flows:
 
-![Data Flows](../images/addon-syncset-installation.png)
+![Data Flows](/addon-syncset-installation.png)
 
 With that in place, OCM will present an "Add-Ons" tab, listing all the Add-Ons
 that your organization has quota for. Example:
 
-![Data Flows](../images/architecture_ocm_ui.png)
+![Data Flows](/architecture_ocm_ui.png)
 
 ## Installation
 
@@ -43,34 +41,32 @@ When you click "Install" in the OCM Web UI, under the hood, OCM creates a
 in Hive. The `SyncSet` object references the cluster in which the addon was just installed in the
 `clusterDeploymentRefs` field.
 
-// TODO: If there is already a SyncSet for an addon is a new one created or is the new cluster name
-just appended to the clusterDeploymentRefs list?
-
-![Data Flows](../images/architecture_install_flow.png)
+![Data Flows](/architecture_install_flow.png)
 [excalidraw](https://excalidraw.com/#room=71d4b0273d4404dbbebf,Pk5KFYj9fFvXSvObY6juCA)
 
 From there, OLM will take over, installing the Operator in the OpenShift
 cluster. While OLM is installing the Operator, OCM will keep polling the
 telemetry  data reported by the cluster, waiting for the `csv_succeeded=1`
 metric from that Operator:
 
-![Data Flows](../images/architecture_telemetry_wait.png)
+![Data Flows](/architecture_telemetry_wait.png)
 
 At some point, when the Operator is fully installed, OCM will reflect that in
 the Web UI:
 
-![Data Flows](../images/architecture_telemetry_done.png)
+![Data Flows](/architecture_telemetry_done.png)
 
 ## Addon Status Lifecycle
 
-![Addon Status Lifecycle](../images/addon-status-ocm.png)
+![Addon Status Lifecycle](/addon-status-ocm.png)
 
 ## Deprecated SelectorSyncSet Installation
-![Data Flows](../images/architecture_data_flow.png)
+
+![Data Flows](/architecture_data_flow.png)
 When you click "Install" in the OCM Web UI, under the hood, OCM will apply
 a label to the corresponding `ClusterDeployment` object in Hive.
 
 That label is the same label used in the `SelectorSyncSet` as a `matchLabel`.
 
 With the `ClusterDeployment` label now matching the `SelectorSyncSet` label,
-Hive will apply all the objects in the `SelectorSyncSet` to the target cluster:
+Hive will apply all the objects in the `SelectorSyncSet` to the target cluster:

content/en/docs/creating-addons/monitoring/deadmanssnitch_integration.md

@@ -5,22 +5,24 @@ date: 2022-12-15T00:53:51+01:00
 ---
 
 ## Overview
+
 [Dead Man's Snitch (DMS)](https://deadmanssnitch.com/) is essentially a constantly firing prometheus alert and an external receiver
 (called a snitch) that will alert should the monitoring stack go down and stop sending alerts.
 The generation of "snitch" urls is dynamic on cluster/add-on installed.
 It's done via the [DMS operator](https://github.com/openshift/deadmanssnitch-operator),
 which runs on hive and is owned by SREP.
 
 ## Usage
+
 The Add-On metadata file (`addon.yaml`) allows you to provide a `deadmanssnitch` field (see `deadmansnitch` field in
 the Add-On metadata file [schema documentation](https://github.com/mt-sre/managed-tenants-cli/blob/main/docs/tenants/zz_metadata_schema_generated.md)
 for more information).
 This field allows you to provide the required Dead Man's Snitch integration configuration. A `DeadmansSnitchIntegration`
 resource is then created and applied to Hive alongside the Add-On [SelectorSyncSet (SSS)](https://github.com/openshift/hive/blob/master/docs/syncset.md#selectorsyncset-object-definition).
 
-
 ### DeadmansSnitchIntegration Resource
-The default DMS configurations which will be created if you specify the bare minimum fields under 'deadmanssnitch' 
+
+The default DMS configurations which will be created if you specify the bare minimum fields under 'deadmanssnitch'
 field in addon metadata:
 
 ```yaml
@@ -30,7 +32,7 @@ field in addon metadata:
     name: addon-{{ADDON.metadata['id']}}
     namespace: deadmanssnitch-operator
   spec:
-    clusterDeploymentSelector: ## can be overriden by .deadmanssnitch.clusterDeploymentSelector field in addon metadata
+    clusterDeploymentSelector: ## can be overridden by .deadmanssnitch.clusterDeploymentSelector field in addon metadata
       matchExpressions:
       - key: {{ADDON.metadata['label']}}
         operator: In
@@ -41,13 +43,13 @@ field in addon metadata:
       name: deadmanssnitch-api-key
       namespace: deadmanssnitch-operator
 
-    snitchNamePostFix: {{ADDON.metadata['id']}} ## can be overriden by .deadmanssnitch.snitchNamePostFix field in addon metadata
+    snitchNamePostFix: {{ADDON.metadata['id']}} ## can be overridden by .deadmanssnitch.snitchNamePostFix field in addon metadata
 
     tags: {{ADDON.metadata['deadmanssnitch']['tags']}} ## Required
 
     targetSecretRef:
-      name: {{ADDON.metadata['id']}}-deadmanssnitch ## can be overriden by .deadmanssnitch.targetSecretRef.name field in addon metadata
-      namespace: {{ADDON.metadata['targetNamespace']}} ## can be overriden by .deadmanssnitch.targetSecretRef.namespace field in addon metadata
+      name: {{ADDON.metadata['id']}}-deadmanssnitch ## can be overridden by .deadmanssnitch.targetSecretRef.name field in addon metadata
+      namespace: {{ADDON.metadata['targetNamespace']}} ## can be overridden by .deadmanssnitch.targetSecretRef.namespace field in addon metadata
 ```
 
 ### Examples of `deadmanssnitch` field in `addon.yaml`
@@ -96,9 +98,10 @@ deadmanssnitch:
     namespace: redhat-rhoami-operator
 ```
 
-### Generated Secret 
-A secrete will be generated (by default in the same namespace as your addon) with the `SNITCH_URL`. 
-Your add-on will need to pick up the generated secret in cluster and inject it into your alertmanager config. 
+### Generated Secret
+
+A secrete will be generated (by default in the same namespace as your addon) with the `SNITCH_URL`.
+Your add-on will need to pick up the generated secret in cluster and inject it into your alertmanager config.
 Example of in-cluster created secret:
 
 ```yaml
@@ -114,6 +117,7 @@ type: Opaque
 ```
 
 ### Alert
+
 Your alertmanager will need a constantly firing alert that is routed to DMS:
 Example of an alert that always fires:
 
@@ -131,6 +135,7 @@ Example of an alert that always fires:
 ```
 
 ## Route
+
 Example of a route that forwards the firing-alert to DMS:
 
 ```yaml
@@ -141,6 +146,7 @@ Example of a route that forwards the firing-alert to DMS:
 ```
 
 ## Receiver
+
 Example receiver for DMS:
 
 ```yaml
@@ -155,13 +161,10 @@ Before going live with the SRES SRE team, they will need to manually point the `
 in the Service Delivery DMS account to their pagerduty service.
 {{% /alert %}}
 
-
 Please log a JIRA with your assigned SRE team to have this completed at least one week before going live with the SRE team.
 
-
-
 ### Current Example
+
 - [RHOAM addon: DMS CR template](https://gitlab.cee.redhat.com/service/managed-tenants/-/blob/09cf5112e7dc5588c14f158d6490f7f1e7051c6a/addons/managed-api-service-internal/metadata/production/deadmanssnitch.yaml.j2)
 - [RHOAM addon: extraResources](https://gitlab.cee.redhat.com/service/managed-tenants/-/blob/09cf5112e7dc5588c14f158d6490f7f1e7051c6a/addons/managed-api-service-internal/metadata/production/addon.yaml#L40) field in `addon.yaml`
 - [RHODS addon: alertmanager configuration](https://github.com/red-hat-data-services/odh-deployer/blob/cb48c55725fd32fdc89a5ff29517b3f4cc0d1f54/monitoring/prometheus/prometheus.yaml)
-// TODO: This 

content/en/docs/creating-addons/monitoring/slo_dashboards.md

@@ -3,20 +3,15 @@ title: "SLO Dashboards"
 date: 2022-12-15T00:53:51+01:00
 ---
 
-// TODO: This might go in a SLI/SLO directory 
-
 Development teams are requested to co-maintain, with the MT-SRE Team, SLO Dashboards for the Addons
-they develop. This document explains how to boostrap the dashboard creation and deployment.
-
-This document does not discuss the content of the dashboard, the topic will be approached in a
-follow-up documentation artifact. // TODO: WHERE???
+they develop. This document explains how to bootstrap the dashboard creation and deployment.
 
 ## First Dashboard
 
 * Fork/clone the [managed-tenants-slos repository](https://gitlab.cee.redhat.com/service/managed-tenants-slos).
 * Create the following directory structure:
 
-```
+```yaml
 ├── <addon-name>
 │   ├── dashboards
 │   │   └── <addon-name>-slo-dashboard.configmap.yaml
@@ -185,7 +180,7 @@ data:
 
 ## Dashboard Deployment
 
-Merging of the above merge request is a prerequisite for this step. 
+Merging of the above merge request is a prerequisite for this step.
 
 The dashboard deployment happens through app-interface, using saas-files.
 
@@ -194,40 +189,42 @@ The dashboard deployment happens through app-interface, using saas-files.
 
 Example Merge Request content to app-interface:
 
-https://gitlab.cee.redhat.com/service/app-interface/-/commit/9306800aabaca18cd034dfb3933a12d29506fa08
+<https://gitlab.cee.redhat.com/service/app-interface/-/commit/9306800aabaca18cd034dfb3933a12d29506fa08>
 
 * Ping `@mt-sre-ic` in the `#forum-managed-tenants` Slack channel for approval.
 * Merge Requests to app-interface are constantly reviewed/merged by AppSRE. After the MT-SRE approval,
   wait until the Merge Request is merged.
 
-# Accessing the Dashboards
+## Accessing the Dashboards
 
 Once the app-interface merge request is merged, you will see your ConfigMaps being deployed in
 the `#sd-mt-sre-info` Slack channel. For example:
 
-```
+```bash
 [app-sre-stage-01] ConfigMap odf-ms-cluster-status applied
 ...
 [app-sre-prod-01] ConfigMap odf-ms-cluster-status applied
 ```
 
 Once the dashboards are deployed, you can see them here:
 
-* STAGE: https://grafana.stage.devshift.net/dashboards/f/aGqy3WB7k/addons
-* PRODUCTION: https://grafana.app-sre.devshift.net/dashboards/f/sDiLLtgVz/addons
+* STAGE: <https://grafana.stage.devshift.net/dashboards/f/aGqy3WB7k/addons>
+* PRODUCTION: <https://grafana.app-sre.devshift.net/dashboards/f/sDiLLtgVz/addons>
 
-# Development Flow
+## Development Flow
 
 After all the configuration is in place:
 
 STAGE:
+
 * Dashboards on the STAGE Grafana instance should not be used by external audiences other than
   the people developing the dashboards.
 * Changes in the `managed-tenants-slos` repository can be merged by the development team with "/lgtm"
   comments from those in the OWNERS file.
 * After merged, changes are automatically delivered to the STAGE grafana instance.
 
 PRODUCTION:
+
 * The dashboards on the PRODUCTION Grafana are pinpointed to a specific git commit from the managed-tenants-slos
   repository in the corresponding saas-file in app-interface.
 * After patching the git commit in the saas-file, owners of the saas-file can merge the promotion

content/en/docs/creating-addons/testing/osde2e.md

@@ -1,3 +1,8 @@
+---
+title: Testing With OSD-E2E
+linkTitle: Testing With OSD-E2E
+---
+
 ## Testing With OSD-E2E
 
 All Add-Ons must have a reference to a test harness container in a publicly
@@ -7,23 +12,26 @@ test harness image. That image is generated by the OSD e2e process.
 The test harness will be tested against OCP nightly and OSD next.
 
 Please refer to the
-[OSD-E2E Add-On Documentation](https://github.com/openshift/osde2e/blob/master/docs/Addons.md)
+[OSD-E2E Add-On Documentation](https://github.com/openshift/osde2e-example-test-harness/blob/main/README.md
 for more details on how this test harness will be run and how it is expected to
 report results.
 
 ## Primer into OSD E2E tests and prow jobs
-To ensure certain things such as validating that the addon can be easily and successfully installed on a customer’s cluster, 
+
+To ensure certain things such as validating that the addon can be easily and successfully installed on a customer’s cluster,
 we have prow jobs setup which run e2e tests (one test suite per addon) every 12 hours.
 If the e2e tests corresponding to any addon fail, then automated alerts/notifications are sent to the addon team.
-Every addon's e2e tests are packaged in an image called “testHarness”, which is built and pushed to [quay.io](https://quay.io) 
+Every addon's e2e tests are packaged in an image called “testHarness”, which is built and pushed to [quay.io](https://quay.io)
 by the team maintaining the addon.
-Once the "testHarness" image is built and pushed, the team must register their addon to testHarness image’s e2e tests 
-by making a PR against this file as it holds the configuration about all the registered e2e tests. For example, this section. ??
+Once the "testHarness" image is built and pushed, the team must register their addon to testHarness image’s e2e tests
+by making a PR against [this file](https://github.com/openshift/release/blob/master/ci-operator/jobs/openshift/osde2e/openshift-osde2e-main-periodics.yaml).
 
-You can access the portal for prow jobs [here](https://prow.ci.openshift.org). The prow jobs follow the below steps to 
+You can access the portal for prow jobs [here](https://prow.ci.openshift.org). The prow jobs follow the below steps to
 run the e2e tests. For every e2e test defined inside [this file](https://github.com/openshift/release/blob/master/ci-operator/jobs/openshift/osde2e/openshift-osde2e-main-periodics.yaml):
-* An OSD cluster is created and the addon, which is being tested, is installed. Openshift API is used to perform these operations via the API definition provided at https://api.openshift.com // TODO: Last sentence not needed?
-* The e2e prow job definition, specifically for the addon from [this file](https://github.com/openshift/release/blob/master/ci-operator/jobs/openshift/osde2e/openshift-osde2e-main-periodics.yaml), is parsed and hence, the parameters required to run its e2e tests will be recognized as well.
-* The "testHarness" image for the addon is parsed and executed against the parameters fetched from the above step. 
-* If an MT-SRE team member notices those tests failing, they should notify the respective team to take a look at them and fix them.
 
+* An OSD cluster is created and the addon, which is being tested, is installed. Openshift API is used to perform these
+operations via the API definition provided at <https://api.openshift.com>
+* The e2e prow job definition, specifically for the addon from [this file](https://github.com/openshift/release/blob/master/ci-operator/jobs/openshift/osde2e/openshift-osde2e-main-periodics.yaml),
+is parsed and hence, the parameters required to run its e2e tests will be recognized as well.
+* The "testHarness" image for the addon is parsed and executed against the parameters fetched from the above step.
+* If an MT-SRE team member notices those tests failing, they should notify the respective team to take a look at them and fix them.

content/en/docs/creating-addons/testing/without-ocm.md

@@ -1,4 +1,9 @@
-## Testing Addons on OCP
+---
+title: Testing With OCP (Without OCM)
+linkTitle: Testing With OCP (Without OCM)
+---
+
+## Testing Without OCM
 
 During the development process, it might be useful (and cheaper) to run your
 addon on an OCP cluster.

content/en/docs/creating-addons/top-level-operator/customer-notifications.md

@@ -4,7 +4,7 @@ date: 2022-12-15T00:53:51+01:00
 ---
 
 There are multiple ways a user or group can get notified of service events (e.g.
-planned maintenance, outages). There are two fields in the addon metadata file 
+planned maintenance, outages). There are two fields in the addon metadata file
 (see Add-On metadata file [schema documentation](https://github.com/mt-sre/managed-tenants-cli/blob/main/docs/tenants/zz_metadata_schema_generated.md)
 for more information) where email addresses can be provided:
 
@@ -14,12 +14,5 @@ for more information) where email addresses can be provided:
 * `addonNotifications`: This is a list of additional email addresses of
   employees who would like to receive notifications about a service.
 
-
 There is also a mailing list that receives notifications for all services managed by Service Delivery.
 Subscribe to the sd-notifications mailing list [here](https://post-office.corp.redhat.com/mailman/listinfo/sd-notifications).
-
-
-
-// TODO: Remove this line? 
-Find out more about App-SRE Incident Procedures
-[here](https://gitlab.cee.redhat.com/service/app-interface/blob/master/docs/app-sre/AAA.md#incident-procedure).

content/en/docs/creating-addons/top-level-operator/dependencies.md

@@ -9,8 +9,7 @@ as signed-off by the Managed Tenants SRE Team.
 ## Dependencies Specification
 
 * Addons must specify dependencies using the OLM dependencies feature,
-  documented
-  [here](https://docs.openshift.com/container-platform/4.7/operators/understanding/olm/olm-understanding-dependency-resolution.html)
+  documented [here](https://docs.openshift.com/container-platform/4.7/operators/understanding/olm/olm-understanding-dependency-resolution.html)
 * The dependencies must have the version pin-pointed. Ranges are not allowed.
 * The dependencies must come from a *Trusted Catalog*. See the
   [Trusted Catalogs](#trusted-catalogs) section for details.
@@ -45,4 +44,5 @@ implemented by CPaaS, or by the Managed Tenants SRE Team.
 
 There's a feature request to the OLM Team to allow specifying the
 CatalogSource used for the dependencies:
+
 * [OLM-2249](https://issues.redhat.com/browse/OLM-2249)

content/en/docs/internal-documentation/_index.md

@@ -0,0 +1,7 @@
+---
+title: Internal Documentation
+linkTitle: Internal Documentation
+weight: 10
+description: >
+    Internal Documentation for the SRE teams.
+---

content/en/docs/internal-documentation/access/_index.md

@@ -0,0 +1,8 @@
+---
+title: "Getting Access"
+linkTitle: "Getting Access"
+weight: 20
+menu:
+  main:
+    weight: 20
+---