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
Copy file name to clipboardexpand all lines: README.md
+12-3
Original file line number
Diff line number
Diff line change
@@ -23,8 +23,9 @@ And libraries:
23
23
*`pkg/lib` - providing external interfaces for interacting with this project as an api that defines a set of standards for operator bundles and indexes.
24
24
*`pkg/containertools` - providing an interface to interact with and shell out to common container tooling binaries (if installed on the environment)
25
25
26
-
# Manifest format
26
+
**NOTE:** The purpose of `opm` tool is to help who needs to manage index catalogues for OLM instances. However, if you are looking for a tool to help you to integrate your operator project with OLM then you should use [Operator-SDK](https://github.com/operator-framework/operator-sdk).
27
27
28
+
# Manifest format
28
29
29
30
We refer to a directory of files with one ClusterServiceVersion as a "bundle". A bundle typically includes a ClusterServiceVersion and the CRDs that define the owned APIs of the CSV in its manifest directory, though additional objects may be included. It also includes an annotations file in its metadata folder which defines some higher level aggregate data that helps to describe the format and package information about how the bundle should be added into an index of bundles.
30
31
@@ -46,7 +47,7 @@ When loading manifests into the database, the following invariants are validated
46
47
47
48
Bundle directories are identified solely by the fact that they contain a ClusterServiceVersion, which provides an amount of freedom for layout of manifests.
48
49
49
-
Check out the [operator bundle design](docs/design/operator-bundle.md) for more detail on the bundle format.
50
+
Check out the [operator bundle design](docs/design/operator-bundle.md) for more detail on the bundle format.
Of course, this build step can be done with any other OCI spec container tools like `docker`, `buildah`, `libpod`, etc.
67
68
69
+
Note that you do not need to create your bundle manually. [Operator-SDK](https://github.com/operator-framework/operator-sdk) provide features and helpers to build, to update, to validate and to test bundles for projects which follows the SDK layout or not. For more information check its documentations over [Integration with OLM](https://sdk.operatorframework.io/docs/olm-integration)
70
+
68
71
# Building an index of Operators using `opm`
69
72
70
73
Now that you have published the container image containing your manifests, how do you actually make that bundle available to other users' Kubernetes clusters so that the Operator Lifecycle Manager can install the operator? This is where the meat of the `operator-registry` project comes in. OLM has the concept of [CatalogSources](https://operator-framework.github.io/olm-book/docs/glossary.html#catalogsources) which define a reference to what packages are available to install onto a cluster. To make your bundle available, you can add the bundle to a container image which the CatalogSource points to. This image contains a database of pointers to bundle images that OLM can pull and extract the manifests from in order to install an operator. So, to make your operator available to OLM, you can generate an index image via opm with your bundle reference included:
@@ -146,7 +149,13 @@ spec:
146
149
147
150
# Using the catalog locally
148
151
149
-
[grpcurl](https://github.com/fullstorydev/grpcurl) is a useful tool for interacting with the example catalog server.
152
+
After starting a catalog locally:
153
+
154
+
```sh
155
+
$ docker run --rm -p 50051:50051 <index image>
156
+
```
157
+
158
+
[grpcurl](https://github.com/fullstorydev/grpcurl) is a useful tool for interacting with the api:
150
159
151
160
```sh
152
161
$ grpcurl -plaintext localhost:50051 list api.Registry
0 commit comments