-
Notifications
You must be signed in to change notification settings - Fork 30
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update API version documentation (#606)
* Update API version documentation * Add new labels descriptio * Apply Tomek's review suggestions * Apply Tomek's review suggestions
- Loading branch information
Showing
5 changed files
with
140 additions
and
79 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,15 +1,39 @@ | ||
| # Lifecycle Manager API | ||
|
|
||
| The Lifecycle Manager API types considers three major pillars that each deal with a specific aspect of reconciling modules into their corresponding states. | ||
| ## Overview | ||
|
|
||
| 1. The introduction of a single entry point CustomResourceDefinition to control a Cluster and it's desired state: The [Kyma custom resource](v1beta1/kyma_types.go) | ||
| 2. The introduction of a single entry point CustomResourceDefinition to control a Module and it's desired state: The [Manifest custom resource](v1beta1/manifest_types.go) | ||
| 3. The [ModuleTemplate custom resource](v1beta1/moduletemplate_types.go) which contains all reference data for the modules to be installed correctly. It is a standardized desired state for a module available in a given release channel. | ||
| The Lifecycle Manager API types consist of three major pillars. Each of these deals with a specific aspect of reconciling modules into their corresponding states. | ||
|
|
||
| Additionally, we maintain the [Watcher custom resource](v1beta1/watcher_types.go) to define callback functionality for synchronized remote clusters that allows lower latencies before changes are detected by the control-plane. | ||
| 1. The introduction of a single entry point CustomResourceDefinition to control a cluster and it's desired state: [Kyma custom resource(CR)](../../../api/v1beta2/kyma_types.go). | ||
| 2. The introduction of a single entry point CustomResourceDefinition to control a module and it's desired state: [Manifest CR](../../../api/v1beta2/manifest_types.go) | ||
| 3. The [ModuleTemplate CR](../../../api/v1beta2/moduletemplate_types.go) which contains all reference data for the modules to be installed correctly. It is a standardized desired state for a module available in a given release channel. | ||
|
|
||
| Read more about the custom resource defininitions in the respective documents: | ||
| Additionally, we maintain the [Watcher custom resource](../../../api/v1beta2/watcher_types.go) to define the callback functionality for synchronized remote clusters that allows lower latencies before changes are detected by the Control Plane. | ||
|
|
||
| ## Custom Resource Definitions | ||
|
|
||
| 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) | ||
|
|
||
| ## Synchronization of Module Catalog with remote clusters | ||
|
|
||
| Lifecycle Manager ensures that 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`. | ||
|
|
||
| By default, without any labels configured on Kyma and ModuleTemplate CRs, a ModuleTemplate CR is synchronized with remote clusters. | ||
|
|
||
| **NOTE:** The ModuleTemplate CRs synchronization is enabled only when Lifecycle Manager runs in the [control-plane mode](../../technical-reference/running-modes). Lifecycle Manager running in the single-cluster mode, doesn't require any CR synchronization. | ||
|
|
||
| **NOTE:** Disabling synchronization for already synchronized ModuleTemplates CRs doesn't remove them from remote clusters. The CRs remain as they are, but any subsequent changes to these ModuleTemplate CRs in the Control Plane are not synchronized. | ||
|
|
||
| For details, read about [the Kyma CR synchronization labels](../api/kyma-cr.md#operatorkyma-projectio-labels) and [the ModuleTemplate CR synchronization labels](../api/moduleTemplate-cr.md#operatorkyma-projectio-labels). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| # API Changelog | ||
|
|
||
| This document represents changes introduced by an API version. | ||
|
|
||
| ## v1beta1 to v1beta2 | ||
|
|
||
| The v1beta1 to v1beta2 version change introduced the following changes to Lifecycle Manager's custom resoucres (CRs). | ||
|
|
||
| ### Kyma CR | ||
|
|
||
| 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.strategy** - replaced with **sync-strategy** annotation in a Kyma CR. By default, the value for the **sync.strategy** annotation is `local-secret`, other values are used for testing purposes only. | ||
| - **.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. |
Oops, something went wrong.