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
- Cache directory should be persistent for production deployments
215
200
- Use `--cache-only` for pre-building cache in CI/CD pipelines
216
201
217
-
## Deprecated SQLite Commands and Operations
218
-
219
-
⚠️ **IMPORTANT DEPRECATION NOTICE**: SQLite-based catalogs and their related subcommands are deprecated. Support for them will be removed in a future release. Please migrate your catalog workflows to the new file-based catalog format.
220
-
221
-
### Deprecated Commands
222
-
223
-
#### `opm registry` Commands (All Deprecated)
224
-
-**`opm registry serve`** - **(Deprecated)** Serve SQLite database via gRPC
225
-
-**`opm registry add`** - **(Deprecated)** Add bundles to SQLite database
226
-
-**`opm registry rm`** - **(Deprecated)** Remove packages from SQLite database
# Convert FBC to a basic catalog template for simpler maintenance
294
-
opm alpha render-template basic ./catalog.yaml
295
-
```
296
-
297
-
### Deprecation Warnings
298
-
299
-
When using deprecated commands, you will see warnings like:
300
-
```
301
-
DEPRECATION NOTICE:
302
-
Sqlite-based catalogs and their related subcommands are deprecated. Support for
303
-
them will be removed in a future release. Please migrate your catalog workflows
304
-
to the new file-based catalog format.
305
-
```
306
-
307
-
**Action Required**: Plan your migration to file-based catalogs to avoid future compatibility issues.
308
-
309
-
### Migration from SQLite to File-Based Catalogs (FBC)
202
+
## Removed SQLite Support
310
203
311
-
#### Using `opm migrate`
312
-
The `opm migrate` command converts SQLite-based index images or database files to file-based catalogs:
204
+
⚠️ **NOTICE**: SQLite-based catalogs and their related commands (`opm registry`, `opm index`) have been removed from this project. All catalog workflows now use the file-based catalog (FBC) format exclusively.
Copy file name to clipboardExpand all lines: README.md
+22-18Lines changed: 22 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,19 +13,13 @@ contribution. See the [DCO](DCO) file for details.
13
13
14
14
This project provides the following binaries:
15
15
16
-
*`opm`, which generates and updates registry databases as well as the index images that encapsulate them.
17
-
*`initializer`, which takes as an input a directory of operator manifests and outputs a sqlite database containing the same data for querying
18
-
* Deprecated - use `opm registry|index add` instead
19
-
*`registry-server`, which takes a sqlite database loaded with manifests, and exposes a gRPC interface to it.
20
-
* Deprecated - use `opm registry serve` instead
21
-
*`configmap-server`, which takes a kubeconfig and a configmap reference, and parses the configmap into the sqlite database before exposing it via the same interface as `registry-server`.
16
+
*`opm`, which manages file-based catalog (FBC) content and the catalog images that encapsulate them.
22
17
23
18
And libraries:
24
19
25
20
*`pkg/client` - providing a high-level client interface for the gRPC api.
26
-
*`pkg/api` - providing low-level client libraries for the gRPC interface exposed by `registry-server`.
21
+
*`pkg/api` - providing low-level client libraries for the gRPC interface.
27
22
*`pkg/registry` - providing basic registry types like Packages, Channels, and Bundles.
28
-
*`pkg/sqlite` - providing interfaces for building sqlite manifest databases from `ConfigMap`s or directories, and for querying an existing sqlite database.
29
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.
30
24
*`pkg/containertools` - providing an interface to interact with and shell out to common container tooling binaries (if installed on the environment)
31
25
@@ -73,26 +67,36 @@ Of course, this build step can be done with any other OCI spec container tools l
73
67
74
68
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)
75
69
76
-
# Building an index of Operators using `opm`
70
+
# Building a catalog of Operators using `opm`
77
71
78
-
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:
72
+
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.
73
+
74
+
To make your bundle available, you build a file-based catalog (FBC) that references your bundle images. You can render bundle images into FBC format and then serve the catalog via a container image.
75
+
76
+
First, render your bundle into a file-based catalog:
79
77
80
78
```sh
81
-
opm index add --bundles quay.io/my-container-registry-namespace/my-manifest-bundle:0.0.1 --tag quay.io/my-container-registry-namespace/my-index:1.0.0
The resulting image is referred to as an "Index". It is an image which contains a database of pointers to operator manifest content that is easily queriable via an included API that is served when the container image is run.
83
+
Then add a channel entry and package definition to your catalog (see the [FBC documentation](https://olm.operatorframework.io/docs/reference/file-based-catalogs/) for the full schema). Once your catalog is assembled, validate it:
86
84
87
-
Now that image is available for clusters to use and reference with CatalogSources on their cluster.
85
+
```sh
86
+
opm validate my-catalog
87
+
```
88
88
89
-
Index images are additive, so you can add a new version of your operator bundle when you publish a new version:
89
+
Generate a Dockerfile and build the catalog image:
90
90
91
91
```sh
92
-
opm index add --bundles quay.io/my-container-registry-namespace/my-manifest-bundle:0.0.2 --from-index quay.io/my-container-registry-namespace/my-index:1.0.0 --tag quay.io/my-container-registry-namespace/my-index:1.0.1
Once the catalog has been loaded, your Operators package definitions are read by the `package-server`, a component of OLM. Watch your Operator packages become available:
0 commit comments