Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Apply Markdown linting in Lifecycle Manager #1603

Merged
merged 2 commits into from
Jun 4, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions .markdownlint.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# This is a configuration file for the markdownlint. You can use this file to overwrite the default settings.
# MD004 checks if the asterisk symbol is used for unordered list items
MD004:
style: asterisk
# MD013 is set to false by default because many files include lines longer than the conventional 80 character limit
MD013: false
# MD024 disable the Multiple headings with the same content rule
MD024: false
# MD029 Set to false because it generates issues with longer lists
MD029: false
# MD033 is set to false to allow for inline HTML elements in a Markdown document
MD033: false
# MD044 is used to set capitalization for particular words. You can determine whether it should be used also for code blocks and HTML elements
MD044:
code_blocks: false
html_elements: false
names:
- Kyma
- Kubernetes
- ConfigMap
- CronJob
- CustomResourceDefinition
- Ingress
- Node
- PodPreset
- Pod
- ProwJob
- Secret
- ServiceBinding
- ServiceClass
- ServiceInstance
42 changes: 21 additions & 21 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,27 +4,27 @@

The `docs` folder contains documentation on the Lifecycle Manager project.

## Table of contents
## Table of Contents

The table of contents lists all the documents in repository with their short description.

- [Developer tutorials](developer-tutorials/README.md) - a directory containing infrastructure-related guides for developers
- [Provide credential for private OCI registry authentication](developer-tutorials/config-private-registry.md)
- [Local test setup in the control-plane mode using k3d](developer-tutorials/local-test-setup.md)
- [Create a test environment on Google Container Registry (GCR)](developer-tutorials/prepare-gcr-registry.md)
- [Provision cluster and OCI registry](developer-tutorials/provision-cluster-and-registry.md)
- [Enable Webhooks in Lifecycle Manager](developer-tutorials/starting-operator-with-webhooks.md)
- Technical reference - a directory with techncial details on Lifecycle Manager, such as architecture, APIs, or running modes
- [API](technical-reference/api/README.md) - a directory with the description of Lifecycle Manager's custom resources (CRs)
- [Kyma CR](technical-reference/api/kyma-cr.md)
- [Manifest CR](technical-reference/api/manifest-cr.md)
- [ModuleTemplate CR](technical-reference/api/moduleTemplate-cr.md)
- [Architecture](technical-reference/architecture.md) - describes Lifecycle Manager's architecture
- [Controllers](technical-reference/controllers.md) - describes Kyma, Manifest and Watcher controllers
- [Running Modes](technical-reference/running-modes.md) - describes Lifecycle Manager's running modes
- [Declarative Reconciliation Library Reference Documentation](/internal/declarative/README.md)
- [Internal Manifest Reconciliation Library Extensions](/internal/manifest/README.md)
- User tutorials
- [Managing module enablement with the CustomResourcePolicy](user-tutorials/02-10-manage-module-with-custom-resource-policy.md)
- [Quick Start](user-tutorials/01-10-control-plane-quick-start.md)
- [Modularization](modularization.md) - describes the modularization concept and its building blocks in the context of Lifecycle Manager
* [Developer tutorials](developer-tutorials/README.md) - a directory containing infrastructure-related guides for developers
* [Provide credential for private OCI registry authentication](developer-tutorials/config-private-registry.md)
* [Local test setup in the control-plane mode using k3d](developer-tutorials/local-test-setup.md)
* [Create a test environment on Google Container Registry (GCR)](developer-tutorials/prepare-gcr-registry.md)
* [Provision cluster and OCI registry](developer-tutorials/provision-cluster-and-registry.md)
* [Enable Webhooks in Lifecycle Manager](developer-tutorials/starting-operator-with-webhooks.md)
* Technical reference - a directory with techncial details on Lifecycle Manager, such as architecture, APIs, or running modes
* [API](technical-reference/api/README.md) - a directory with the description of Lifecycle Manager's custom resources (CRs)
* [Kyma CR](technical-reference/api/kyma-cr.md)
* [Manifest CR](technical-reference/api/manifest-cr.md)
* [ModuleTemplate CR](technical-reference/api/moduleTemplate-cr.md)
* [Architecture](technical-reference/architecture.md) - describes Lifecycle Manager's architecture
* [Controllers](technical-reference/controllers.md) - describes Kyma, Manifest and Watcher controllers
* [Running Modes](technical-reference/running-modes.md) - describes Lifecycle Manager's running modes
* [Declarative Reconciliation Library Reference Documentation](/internal/declarative/README.md)
* [Internal Manifest Reconciliation Library Extensions](/internal/manifest/README.md)
* User tutorials
* [Managing module enablement with the CustomResourcePolicy](user-tutorials/02-10-manage-module-with-custom-resource-policy.md)
* [Quick Start](user-tutorials/01-10-control-plane-quick-start.md)
* [Modularization](modularization.md) - describes the modularization concept and its building blocks in the context of Lifecycle Manager
2 changes: 1 addition & 1 deletion docs/developer-tutorials/README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
# Developer tutorials
# Developer Tutorials

This directory contains infrastructure-related developer tutorials around Lifecycle Manager.
6 changes: 3 additions & 3 deletions docs/developer-tutorials/config-private-registry.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Provide credentials for private OCI registry authentication
# Provide Credentials for Private OCI Registry Authentication

## Context

Expand All @@ -16,7 +16,7 @@ Before you proceed, prepare your registry credentials. Check also how to deal wi

## Procedure

### Prepare a docker-registry Secret manifest
### Prepare a docker-registry Secret Manifest

1. Create a docker-registry Secret manifest. Run:

Expand All @@ -39,7 +39,7 @@ Before you proceed, prepare your registry credentials. Check also how to deal wi

3. Deploy the Secret on the same cluster where the ModuleTemplate CR is to be located. For example, if the ModuleTemplate CR is on the SKR cluster, then the Secret should be deployed to the SKR. Otherwise, it should be deployed to the KCP cluster.

### Generate a ModuleTemplate CR with the `oci-registry-cred` label
### Generate a ModuleTemplate CR with the `oci-registry-cred` Label

The `oci-registry-cred` label in a ModuleTemplate CR allows Lifecycle Manager to parse the Secret label selector and propagate it to the Manifest CR so that Lifecycle Manager knows which credentials Secret to look up.

Expand Down
26 changes: 13 additions & 13 deletions docs/developer-tutorials/local-test-setup.md
Original file line number Diff line number Diff line change
@@ -1,26 +1,26 @@
# Local test setup in the control-plane mode using k3d
# Local test Setup in the control-plane Mode Using k3d

## Context

This tutorial shows how to configure a fully working e2e test setup including the following components:

- Lifecycle Manager
- Runtime Watcher on a remote cluster
- `template-operator` on a remote cluster as an example
* Lifecycle Manager
* Runtime Watcher on a remote cluster
* `template-operator` on a remote cluster as an example

This setup is deployed with the following security features enabled:

- Strict mTLS connection between Kyma Control Plane (KCP) and SKR clusters
- SAN Pinning (SAN of client TLS certificate needs to match the DNS annotation of a corresponding Kyma CR)
* Strict mTLS connection between Kyma Control Plane (KCP) and SKR clusters
* SAN Pinning (SAN of client TLS certificate needs to match the DNS annotation of a corresponding Kyma CR)

> **NOTE:** If you want to use remote clusters instead of a local k3d setup or external registries, please refer to the following guides for the cluster and registry setup:
>
> - [Provision cluster and OCI registry](provision-cluster-and-registry.md)
> - [Create a test environment on Google Container Registry (GCR)](prepare-gcr-registry.md)
> * [Provision cluster and OCI registry](provision-cluster-and-registry.md)
> * [Create a test environment on Google Container Registry (GCR)](prepare-gcr-registry.md)

## Procedure

### KCP cluster setup
### KCP Cluster Setup

1. Create a local KCP cluster:

Expand Down Expand Up @@ -137,15 +137,15 @@ This setup is deployed with the following security features enabled:
kubectl apply -f ./template.yaml
```

### SKR cluster setup
### SKR Cluster Setup

Create a local Kyma runtime (SKR) cluster:

```shell
k3d cluster create skr-local
```

### Create a Kyma CR and a remote Secret
### Create a Kyma CR and a Remote Secret

1. Switch the context for using the KCP cluster:

Expand Down Expand Up @@ -216,7 +216,7 @@ k3d cluster create skr-local

</details>

### Watcher and module installation verification
### Watcher and Module Installation Verification

Check the Kyma CR events to verify if the `SKRWebhookIsReady` condition is set to `True`.
Also make sure if the state of the `template-operator` is `Ready` and check the overall `state`.
Expand Down Expand Up @@ -257,7 +257,7 @@ status:
state: Ready
```

### (Optional) Check the functionality of the Watcher component
### (Optional) Check the Functionality of the Watcher Component

1. Switch the context to use the SKR cluster:

Expand Down
6 changes: 3 additions & 3 deletions docs/developer-tutorials/prepare-gcr-registry.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Create a test environment on Google Container Registry (GCR)
# Create a test Environment on Google Container Registry (GCR)

## Context

Expand All @@ -10,7 +10,7 @@ This tutorial assumes that you have a GCP project called `sap-kyma-jellyfish-dev

## Procedure

### Create your repository
### Create your Repository

1. Create an Artifact Registry repository. For tutorial purposes, call it `operator-test`.

Expand All @@ -27,7 +27,7 @@ This tutorial assumes that you have a GCP project called `sap-kyma-jellyfish-dev
--location=europe-west3 --member=allUsers --role=roles/artifactregistry.reader
```

### Authenticate locally and create a service account in Google Cloud
### Authenticate Locally and Create a Service Account in Google Cloud

1. Under the assumption you're [creating and using a service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) called `operator-test-sa`, authenticate against your registry:

Expand Down
10 changes: 5 additions & 5 deletions docs/developer-tutorials/provision-cluster-and-registry.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Provision a cluster and OCI registry
# Provision a Cluster and OCI Registry

## Context

Expand All @@ -8,7 +8,7 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)

## Procedure

### Local cluster setup
### Local Cluster Setup

1. Create a `k3d` cluster:

Expand All @@ -31,14 +31,14 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)

3. Set the `IMG` environment variable for the `docker-build` and `docker-push` commands, to make sure images are accessible by local k3d clusters.

- For the **single-cluster mode**:
* For the **single-cluster mode**:

```sh
# pointing to KCP registry in dual cluster mode
export IMG=op-kcp-registry.localhost:8888/unsigned/operator-images
```

- For the **control-plane mode**:
* For the **control-plane mode**:

```sh
# pointing to SKR registry in dual cluster mode
Expand All @@ -47,7 +47,7 @@ For the control-plane mode, with Kyma Control Plane (KCP) and Kyma runtime (SKR)

4. Once you pushed your image, verify the content. For browsing through the content of the local container registry, use, for example, `http://op-kcp-registry.localhost:8888/v2/_catalog?n=100`.

### Remote cluster setup
### Remote Cluster Setup

Learn how to use a Gardener cluster for testing.

Expand Down
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Enable webhooks in Lifecycle Manager
# Enable Webhooks in Lifecycle Manager

## Context

Expand Down
14 changes: 7 additions & 7 deletions docs/technical-reference/api/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,21 +14,21 @@ Additionally, we maintain the [Watcher CR](/api/v1beta2/watcher_types.go) to def

Read more about the custom resource definitions (CRDs) in the respective documents:

- [Kyma CR](kyma-cr.md)
- [Manifest CR](manifest-cr.md)
- [ModuleTemplate CR](moduleTemplate-cr.md)
* [Kyma CR](kyma-cr.md)
* [Manifest CR](manifest-cr.md)
* [ModuleTemplate CR](moduleTemplate-cr.md)

## Synchronization of Module Catalog with remote clusters
## Synchronization of Module Catalog with Remote Clusters

Lifecycle Manager ensures the Module Catalog is correctly synchronized with users' runtimes.
The Module Catalog consists of all modules, represented by ModuleTemplates CR, that are available for a user. The Module Catalog portfolio may vary for different users.
The synchronization mechanism described below is essential to allow users to enable modules in their clusters.
The mechanism is controlled by the set of labels that are configured on Kyma and ModuleTemplate CRs in the Control Plane. The labels are: `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta`.
The v1beta2 API introduces three groups of modules:

- Default modules, synchronized by default.
- Internal modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `internal`, use the `operator.kyma-project.io/internal` label and set it to `true`.
- Beta modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `beta`, use the `operator.kyma-project.io/beta` label and set it to `true`.
* Default modules, synchronized by default.
* Internal modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `internal`, use the `operator.kyma-project.io/internal` label and set it to `true`.
* Beta modules, synchronized per-cluster only if configured explicitly on the corresponding Kyma CRs. To mark a ModuleTemplate CR as `beta`, use the `operator.kyma-project.io/beta` label and set it to `true`.

By default, without any labels configured on Kyma and ModuleTemplate CRs, a ModuleTemplate CR is synchronized with remote clusters.

Expand Down
10 changes: 5 additions & 5 deletions docs/technical-reference/api/changelog.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,13 +10,13 @@ The v1beta1 to v1beta2 version change introduced the following changes to Lifecy

The main change introduced to the Kyma CRD is the removal of the **.spec.sync** attribute. As a result, the v1beta1 **.spec.sync** sub-attributes handling changes as described:

- **.sync.enabled** - replaced by the `operator.kyma-project.io/sync` label in a Kyma CR. For details, read the [Kyma CR synchronization labels](link TBD) document.
- **.sync.moduleCatalog** - replaced by a combination the `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta` labels in Kyma and ModuleTemplate CRs. For details, read the [Kyma CR synchronization labels](link TBD) document.
- **.sync.namespace** - replaced with a `sync-namespace` command-line flag for Lifecycle Manager. It means that a user can no longer configure the Namespace synchronized with a particular Kyma CR. The Namespace is the same for all Kyma CRs in a given Lifecycle Manager instance, and a user can't change it.
- **.sync.noModuleCopy** - removed. Currently, the **.spec.modules[]** for a remote Kyma CR is always initialized as empty.
* **.sync.enabled** - replaced by the `operator.kyma-project.io/sync` label in a Kyma CR. For details, read the [Kyma CR synchronization labels](link TBD) document.
* **.sync.moduleCatalog** - replaced by a combination the `operator.kyma-project.io/sync`, `operator.kyma-project.io/internal`, and `operator.kyma-project.io/beta` labels in Kyma and ModuleTemplate CRs. For details, read the [Kyma CR synchronization labels](link TBD) document.
* **.sync.namespace** - replaced with a `sync-namespace` command-line flag for Lifecycle Manager. It means that a user can no longer configure the Namespace synchronized with a particular Kyma CR. The Namespace is the same for all Kyma CRs in a given Lifecycle Manager instance, and a user can't change it.
* **.sync.noModuleCopy** - removed. Currently, the **.spec.modules[]** for a remote Kyma CR is always initialized as empty.

### ModuleTemplate CR

In the ModuleTemplate CRD the changes relate to the **sync.target** attribute:

- `.sync.target` - replaced with a `in-kcp-mode` command-line flag for Lifecycle Manager. It means that a user can no longer configure the ModuleTemplate synchronization. The configuration is the same for all ModuleTemplate CRs in a given Lifecycle Manager instance, and a user can't change it.
* `.sync.target` - replaced with a `in-kcp-mode` command-line flag for Lifecycle Manager. It means that a user can no longer configure the ModuleTemplate synchronization. The configuration is the same for all ModuleTemplate CRs in a given Lifecycle Manager instance, and a user can't change it.
Loading
Loading