You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(registry): Add label dependency constraint and property
1. Introduce a new type of dependency constraint named `olm.label` which
represents the constraints that are based on CSV labels.
2. The new label property is parsed from CSV labels.
Signed-off-by: Vu Dinh <[email protected]>
Copy file name to clipboardexpand all lines: docs/design/operator-bundle.md
+5-2
Original file line number
Diff line number
Diff line change
@@ -69,21 +69,24 @@ annotations:
69
69
70
70
The dependencies of an operator are listed as a list in `dependencies.yaml` file inside `/metadata` folder of a bundle. This file is optional and only used to specify explicit operator version dependencies at first. Eventually, operator authors can migrate the API-based dependencies into `dependencies.yaml` as well in the future. The ultimate goal is to have `dependencies.yaml` as a centralized metadata for operator dependencies and moving the dependency information away from CSV.
71
71
72
-
The dependency list will contain a `type` field for each item to specify what kind of dependency this is. There are two supported `type` of operator dependencies. It can be a package type (`olm.package`) meaning this is a dependency for a specific operator version. For `olm.package` type, the dependency information should include the `package` name and the `version` of the package in semver format. We use `blang/semver` library for semver parsing (https://github.com/blang/semver). For example, you can specify an exact version such as `0.5.2` or a range of version such as `>0.5.1` (https://github.com/blang/semver#ranges). In addition, the author can specify dependency that is similiar to existing CRD/API-based using `olm.gvk` type and then specify GVK information as how it is done in CSV. This is a path to enable operator authors to consolidate all dependencies (API or explicit version) to be in the same place.
72
+
The dependency list will contain a `type` field for each item to specify what kind of dependency this is. There are two supported `type` of operator dependencies. It can be a package type (`olm.package`) meaning this is a dependency for a specific operator version. For `olm.package` type, the dependency information should include the `package` name and the `version` of the package in semver format. We use `blang/semver` library for semver parsing (https://github.com/blang/semver). For example, you can specify an exact version such as `0.5.2` or a range of version such as `>0.5.1` (https://github.com/blang/semver#ranges). In addition, the author can specify dependency that is similar to existing CRD/API-based using `olm.gvk` type and then specify GVK information as how it is done in CSV. The author can also specify CSV labels as dependency constraints using `olm.label` type. The value of `olm.label` type will be matched against labels in CSV with the key starting with the phrase `olm.label`. This is a path to enable operator authors to consolidate all dependencies (API or explicit version) to be in the same place.
73
73
74
74
An example of a `dependencies.yaml` that specifies Prometheus operator and etcd CRD dependencies:
Copy file name to clipboardexpand all lines: pkg/lib/bundle/testdata/validate/invalid_dependencies_bundle/invalid_label_dependency/manifests/etcdoperator.v0.9.4.clusterserviceversion.yaml
0 commit comments