Merge pull request #44 from mmitoraj/operator

Add the operator folder to the template

docs/README.md

@@ -2,12 +2,14 @@
 
 ## Overview
 
-The `docs` folder contains two subfolders - `user` and `contributor`. 
+The `docs` folder contains three subfolders - `user`, `contributor`, and `operator`[^*].
 
-The `user` subfolder contains the end-user documentation, which is displayed on the [Kyma website](https://kyma-project.io/#/). Depending on your module needs, the subfolder must include overview, usage, or technical reference documents. To display the content on the website properly, create a `_sidebar.md` file in the `user` subfolder and list the documents it contains there. For more information on how to publish user documentation, follow [this guide](https://github.com/kyma-project/community/blob/main/docs/guidelines/content-guidelines/01-user-docs.md).
+The `user` subfolder contains the end-user documentation, which is displayed on the [Kyma website](https://kyma-project.io/#/) and in the SAP Help Portal. Depending on your module needs, the subfolder must include overview, usage, or technical reference documents. To display the content on the website properly, create a `_sidebar.md` file in the `user` subfolder and list the documents it contains there. For more information on how to publish user documentation, follow [this guide](https://github.com/kyma-project/community/blob/main/docs/guidelines/content-guidelines/01-user-docs.md).
 
 The `contributor` subfolder includes any developer-related documentation to help them manually install, develop, and operate a module.
 
+The `operator` subfolder is mandatory only if your module/component is delivered to restricted markets. The subfolder includes documentation relevant to the respective operators.
+
 To have a common structure across all modules, all documents must be properly numbered according to the following structure:
 
 > **NOTE:** It is suggested to use the following titles if you have the content that matches them; otherwise use your own, more suitable titles, or simply skip the ones you find irrelevant.
@@ -32,8 +34,11 @@ where `xx` is the number of the given document. For example:
    02-30-use-metrics
    (...)
    ```
+
 > **NOTE:** Before introducing [docsify](https://docsify.js.org/#/?id=docsify), we agreed to use the `10`, `20`, `30` numbering. It was to help maintain the proper order of docs if they were rendered automatically on the website. With docsify, you manually add the content to the `_sidebar.md` file, and docs are displayed in the order you add them. However, this numbering is still recommended to have the unified structure of the docs in the module repositories.
-      
+
 If you have other content that does not fit into the above topics, create your own 04-10-module-specific document(s).
 
-You can divide your documentation into subfolders to avoid having too many documents in one `docs/user` or `docs/contributor` folder. For example, if you have many technical reference documents, you can create a `technical reference` subfolder in `docs/user` and keep relevant documentation there. Each subfolder in the `user` folder must have its own `_sidebar.md` file with the links to the main module page and the list of docs it contains.
+You can divide your documentation into subfolders to avoid having too many documents in one `docs/user` or `docs/contributor` folder. For example, if you have many technical reference documents, you can create a `technical reference` subfolder in `docs/user` and keep relevant documentation there. Each subfolder in the `user` folder must have its own `_sidebar.md` file with the links to the main module page and the list of docs it contains.
+
+[^*]: Only in documentation for restricted markets.

docs/operator/README.md

@@ -0,0 +1,7 @@
+This folder is mandatory only if your module/component is delivered to restricted markets. It includes documentation relevant to the respective operators.
+
+## General Guidelines
+
+Our target persona has a good knowledge of the technical concepts involved, and does not need a detailed breakdown of steps at the click-level. If there are complicated procedures, use your judgment to break it into steps for easy consumption.
+
+Although the target persona has the technical knowledge, they don't know Kyma specifics. Explain all the Kyma-related concepts and steps thoroughly with attention to details and understanding for the target user perspective.

docs/operator/cn/01-10-installation.md

@@ -0,0 +1,17 @@
+# Installing {Component Name}
+
+## Prerequisites
+
+<!--Describe the prerequisites for installing your service (if there are some). For example:
+- List the components that your component depends on
+- List the BTP integrations used by your component-->
+
+## Procedure
+
+<!--Describe the installation steps in a logical sequence.-->
+
+## Post-Installation Steps
+
+<!--Describe any post-installation steps that you might need, including the initial setup of your monitors. Setting up monitors should also be part of your operations topic. However, please include this information here as well.-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-InstallationandUpdate)-->

docs/operator/cn/02-10-update.md

@@ -0,0 +1,24 @@
+# Updating {Component Name}
+
+## Prerequisites
+
+<!--Describe the prerequisites for updating your service (if there are some).-->
+
+## What's Changed {OPTIONAL}
+
+<!--In this optional section, describe significat changes since the last minor or major release. For example:
+- Operation changes
+- New functionalities
+- Deprecated functionalities
+- Configuration changes
+- Updating pitfalls-->
+
+## Procedure
+
+<!--Describe the update steps in a logical sequence.-->
+
+## Post-Update Steps
+
+<!--Describe any post-update steps that you might need. If monitors need to be recreated after an update, add this information to the update structure of your service/component.-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-InstallationandUpdate)-->

docs/operator/cn/03-10-operations.md

@@ -0,0 +1,33 @@
+# {Component/Service Name} - Operations
+
+<!--Please create only one single document with multiple sections for your Operations documentation. Our goal is to display all Operations content for a service on a single page so that the operators can quickly search for information using the search function.-->
+
+<!--Recommended sections:
+## Configuration
+
+Desribe Helm charts parameters and configuration values used during installation. 
+
+Provide details on  any injected configuration that the component expects. For example, ConfigMaps and/or Secrets.
+
+## REST API {if applicable}
+
+## Custom Resources
+
+In this section, describe:
+- The component's CRs and their purpose
+- CRs' backup requirements (Is it regenerated or does it require backup?)
+- CRs' mechanics
+- CRs' labels and annotations 
+
+## Metrics
+
+In this section describe:
+- What metrics endpoints does the component use? What is the metrics format? (Prometheus is expected)
+- What metrics are presented on each endpoint? Describe all the metrics and what they represent.
+- Provide the recommended way to determine warnings and identify critical values in metrics.
+
+Consider describing some recommendations regarding conditions and thresholds for triggering alerts.
+
+-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-OperationsDocumentation)-->

docs/operator/cn/04-10-troubleshooting.md

@@ -0,0 +1,8 @@
+# {Component/Service Name} - Troubleshooting
+
+<!--
+- Use a problem-solution format, where a problem can be a statement or a question.
+- If you have multiple solutions, provide the recommended solution first.
+- Provide all recommended actions and introduce a connection to the alerts of your service, preferably the monitor name.-->
+
+<!--For more information, see [Documentation Guidelines for Troubleshooting Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-TroubleshootingDocumentation)-->

docs/operator/cn/README.md

@@ -0,0 +1,10 @@
+This folder includes documentation relevant to the China cloud operator. The documentation is published as part of the [SAP BTP, Partner-Managed Edition](https://help.sap.com/docs/CPOPS?state=DRAFT) official documentation in the SAP Help Portal.
+
+The mandatory documentation types include:
+
+- Installation
+- Update
+- Operations
+- Troubleshooting
+
+You will find the respective files for each documentation type in the template file structure.

docs/operator/ns2/01-10-installation.md

@@ -0,0 +1,17 @@
+# Installing {Component Name}
+
+## Prerequisites
+
+<!--Describe the prerequisites for installing your service (if there are some). For example:
+- List the components that your component depends on
+- List the BTP integrations used by your component-->
+
+## Procedure
+
+<!--Describe the installation steps in a logical sequence.-->
+
+## Post-Installation Steps
+
+<!--Describe any post-installation steps that you might need, including the initial setup of your monitors. Setting up monitors should also be part of your operations topic. However, please include this information here as well.-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-InstallationandUpdate)-->

docs/operator/ns2/02-10-update.md

@@ -0,0 +1,24 @@
+# Updating {Component Name}
+
+## Prerequisites
+
+<!--Describe the prerequisites for updating your service (if there are some).-->
+
+## What's Changed {OPTIONAL}
+
+<!--In this optional section, describe significat changes since the last minor or major release. For example:
+- Operation changes
+- New functionalities
+- Deprecated functionalities
+- Configuration changes
+- Updating pitfalls-->
+
+## Procedure
+
+<!--Describe the update steps in a logical sequence.-->
+
+## Post-Update Steps
+
+<!--Describe any post-update steps that you might need. If monitors need to be recreated after an update, add this information to the update structure of your service/component.-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-InstallationandUpdate)-->

docs/operator/ns2/03-10-operations.md

@@ -0,0 +1,32 @@
+# {Component/Service Name} - Operations
+
+<!--Please create only one single document with multiple sections for your Operations documentation. Our goal is to display all Operations content for a service on a single page so that the operators can quickly search for information using the search function.-->
+
+<!--Recommended sections:
+## Configuration
+
+Desribe Helm charts parameters and configuration values used during installation. 
+
+Provide details on  any injected configuration that the component expects. For example, ConfigMaps and/or Secrets.
+
+## REST API {if applicable}
+
+## Custom Resources
+
+In this section, describe:
+- The component's CRs and their purpose
+- CRs' backup requirements (Is it regenerated or does it require backup?)
+- CRs' mechanics
+- CRs' labels and annotations 
+
+## Metrics
+
+In this section describe:
+- What metrics endpoints does the component use? What is the metrics format? (Prometheus is expected)
+- What metrics are presented on each endpoint? Describe all the metrics and what they represent.
+- Provide the recommended way to determine warnings and identify critical values in metrics.
+
+Consider describing some recommendations regarding conditions and thresholds for triggering alerts.
+-->
+
+<!--For more information, see [Documentation Guidelines for Operator Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-OperationsDocumentation)-->

docs/operator/ns2/04-10-troubleshooting.md

@@ -0,0 +1,8 @@
+# {Component/Service Name} - Troubleshooting
+
+<!--
+- Use a problem-solution format, where a problem can be presented as a statement or a question.
+- If you have multiple solutions, provide the recommended solution first.
+- Provide all recommended actions and introduce a connection to the alerts of your service, preferably the monitor name.-->
+
+<!--For more information, see [Documentation Guidelines for Troubleshooting Documentation](https://wiki.one.int.sap/wiki/display/NDW/Documentation+Guidelines+for+Operator+Documentation#DocumentationGuidelinesforOperatorDocumentation-TroubleshootingDocumentation)-->

docs/operator/ns2/README.md

@@ -0,0 +1,10 @@
+This folder includes documentation relevant to the NS2 operator. The documentation is published as part of the [SAP BTP, Partner-Managed Edition (AWS GovCloud)](https://help.sap.com/docs/OPSAWS?state=DRAFT) official documentation in the SAP Help Portal.
+
+The mandatory documentation types include:
+
+- Installation
+- Update
+- Operations
+- Troubleshooting
+
+You will find the respective files for each documentation type in the template file structure.