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.

Sign up for GitHub

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

Jump to bottom

Fix typos and outdated info on bundle enhancement doc #82

Closed
wants to merge 1 commit into from
Closed

Fix typos and outdated info on bundle enhancement doc #82

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
34 changes: 14 additions & 20 deletions enhancements/olm/operator-bundle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ The focus of this user story is to define a standard to store, transmit, inspect
* For an operator The metadata can be downloaded independently of the manifest.

### Implementation Details/Notes/Constraints
* The initial implementation target will be Docker v2-2 `manifests`, `manifest-lists`, and docker client support, for maximum compatiblity with existing tooling.
* The initial implementation target will be Docker v2-2 `manifests`, `manifest-lists`, and docker client support, for maximum compatibility with existing tooling.
* We want the entire operator bundle to be identifiable and retrievable using the same identifier/URL.

#### Docker
Expand All @@ -77,9 +77,9 @@ The focus of this user story is to define a standard to store, transmit, inspect
We use the following labels to annotate the operator bundle image.
* The label `operators.operatorframework.io.bundle.manifests.v1` reflects the path in the image to the directory that contains the operator manifests.
* The label `operators.operatorframework.io.bundle.metadata.v1` reflects the path in the image to the directory that contains metadata files about the bundle.
* The `v1.manifests` and `v1.metadata` labels imply the bundle type:
* The value `v1.manifests` implies that this bundle contains operator manifests.
* The value `v1.metadata` implies that this bundle has operator metadata.
* The `manifests.v1` and `metadata.v1` labels imply the bundle type:
* The value `manifests.v1` implies that this bundle contains operator manifests.
* The value `metadata.v1` implies that this bundle has operator metadata.
* The label `operators.operatorframework.io.bundle.mediatype.v1` reflects the media type or format of the operator bundle. It could be helm charts, plain kubernetes manifests etc.
* The label `operators.operatorframework.io.bundle.package.v1` reflects the package name of the bundle.
* The label `operators.operatorframework.io.bundle.channels.v1` reflects the list of channels the bundle is subscribing to when added into an operator registry
Expand All @@ -103,14 +103,14 @@ annotations:
* The potential use case for the `LABELS` is - an external off-cluster tool can inspect the image to check the type of a given bundle image without downloading the content.

###### Format
We can use the following values for `mediatype`:
* `registry`: Format used by [Operator Registry](https://github.com/operator-framework/operator-registry#manifest-format) to package an operator.
We can use the following values for `mediatype`:
* `registry+v1`: Format used by [Operator Registry](https://github.com/operator-framework/operator-registry#manifest-format) to package an operator.
* `helm`: Can be used to package a helm chart inside an operator bundle.
* `plain`: Can be used to package plain k8s manifests inside an operator bundle.

An operator author can also specify the version of the format used inside the bundle. For example,
```yaml
operators.operatorframework.io.bundle.mediatype: "registry+v1"
operators.operatorframework.io.bundle.mediatype.v1: "registry+v1"
```

###### Graph Metadata
Expand Down Expand Up @@ -166,14 +166,14 @@ test
```
FROM scratch

# We are pushing an operator-registry bundle
# We are pushing an operator-registry bundle
# that has both metadata and manifests.
LABEL operators.operatorframework.io.bundle.mediatype.v1=registry+v1
LABEL operators.operatorframework.io.bundle.manifests.v1=manifests/
LABEL operators.operatorframework.io.bundle.metadata.v1=metadata/
LABEL operators.operatorframework.io.bundle.package.v1: "etcd"
LABEL operators.operatorframework.io.bundle.channels.v1: "alpha,stable"
LABEL operators.operatorframework.io.bundle.channel.default.v1: "stable"
LABEL operators.operatorframework.io.bundle.package.v1=etcd
LABEL operators.operatorframework.io.bundle.channels.v1=alpha,stable
LABEL operators.operatorframework.io.bundle.channel.default.v1=stable

ADD ./test/*.yaml /manifests/
ADD test/annotations.yaml /metadata/annotations.yaml
Expand Down Expand Up @@ -208,15 +208,9 @@ docker pull quay.io/test/test-operator:v1

A tool can inspect an operator bundle image to determine the bundle type and its format.
```bash
# inspect the type of the operator bundle.
docker image inspect quay.io/test/test-operator:v1 | \
jq '.[0].Config.Labels["operators.operatorframework.io.bundle.resources"]'

"manifests+metadata"

# inspect the format of the operator bundle.
docker image inspect quay.io/test/test-operator:v1 | \
jq '.[0].Config.Labels["operators.operatorframework.io.bundle.mediatype"]'
jq '.[0].Config.Labels["operators.operatorframework.io.bundle.mediatype.v1"]'

"registry+v1"
```
Expand All @@ -237,11 +231,11 @@ test
$ cd test

# the following command generates the necessary scaffolding.
$ operator-framework bundle init --type=registry --bundle-folder=0.1.0
$ operator-sdk bundle generate --directory /test/ --package test-operator --channels stable

# output:
# - test/Dockerfile
# - test/annotations.yaml
# - test/metadata/annotations.yaml
```

Once the scaffolding is generated the user can do a `docker build` to create an operator bundle image.
Expand Down