doc/proposals/sdk-integration-with-olm.md: SDK/OLM integration… #1913
Conversation
…for SDK/OLM integration
openshift-ci-robot
requested review from
dangeoffroy,
dmesser and
joelanford
openshift-ci-robot
added
the
size/L
|
/test marker |
1 similar comment
|
/test marker |
|
/test e2e-aws-ansible |
| Include as much detail as possible so that people can understand the "how" of | ||
| the system. The goal here is to make this feel real for users without getting | ||
| bogged down. | ||
|
|
There was a problem hiding this comment.
shows that this part could be removed.
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| Initial PR: https://github.com/operator-framework/operator-sdk/pull/1912 |
There was a problem hiding this comment.
Should we add here the PR's? Should not have here the descriptions/proposals?
|
|
||
| The SDK's approach to deployment should be as general and reliant on existing mechanisms as possible. To that end, [`operator-registry`][registry] should be used since it defines what a bundle contains and how one is structured. `operator-registry` libraries should be used to create and serve bundles, and interact with package manifests. | ||
|
|
||
| The idea is to create a `Deployment` containing the latest `operator-registry` [image][registry-image] to initialize a bundle database and run a registry server serving that database using binaries contained in the image. The `Deployment` will contain volume mounts from a `ConfigMap` containing bundle files and a package manifest for an operator. Using manifest data in the `ConfigMap` volume source, the registry initializer can build a local database and serve that database through the `Service`. OLM-specific resources created by the SDK or supplied by a user, described below, will establish communication between this registry server and OLM. |
There was a problem hiding this comment.
This part is not clear to me. Will we change what a bundle is currently?.
Should we not just generate the bundle files in the path project/deploy/olm-catalog/<project-name>? So, in this way, I understand that SDK tool would be able to:
- Generate the CSV file and copy the CRD's for
project/deploy/olm-catalog/<project-name>/<tag>- (this part is already done currently with the commandoperator-sdk olm-catalog gen-csv --csv-version 0.1.0 --update-crds) - Then, we need to create the pkg file as this example - (it is what we need to impl to be done by SDK commands
operator-sdk olm-catalogas well)
Following my suggestion for this story:
Operator developers can useoperator-sdkto create the bundle files
And the description could be something as:
The files which are required to create the bundle are defined here.
Note that the operator-sdk olm-catalog commands are able to create the CSV and copy the CRD's for
project/deploy/olm-catalog/<project-name>/<tag>then it would also be able to create the package file as this example. Also, note that https://operatorhub.io/bundle has a feature to do the same and then it should be aligned to it.
WDYT?
| OLM understands `operator-registry` servers and served data through several objects. A [`CatalogSource`][olm-catalogsource] specifies how to communicate with a registry server. A [`Subscription`][olm-subscription] links a particular CSV channel to a `CatalogSource`, indicating from which `CatalogSource` OLM should pull an Operator. Another OLM resource that _may_ be required is an [`OperatorGroup`][olm-operatorgroup], which provides Operator namespacing information to OLM; OLM creates two `OperatorGroup`'s by default, one of which can be used for globally scoped Operators. | ||
|
|
||
| These resources can be created from bundle data with minimal user input. They can also be created from manifests defined by the user; however, the SDK cannot make guarantees that user-defined manifests will work as expected. | ||
|
|
There was a problem hiding this comment.
I think we could specify here what resources we are speaking about and link its docs as to where it would be created too. E.g here in my project I created the path <project-name>/deploy/olm-catalog/olm-test since it can be used just to test it locally. See here
Then, I understand that this story should be as for example:
Operator developers should be able to create the olm files to check my operator project locally.
And the description would be something as:
The files required to test the app locally are X and it is defined here. One example of it is here
|
|
||
| Initial PR: https://github.com/operator-framework/operator-sdk/pull/1912 | ||
|
|
||
| #### Use of operator-registry |
There was a problem hiding this comment.
IMHO: It goal should be an story
|
|
||
| These resources can be created from bundle data with minimal user input. They can also be created from manifests defined by the user; however, the SDK cannot make guarantees that user-defined manifests will work as expected. | ||
|
|
||
| #### Use of operator-framework/api validation |
There was a problem hiding this comment.
It shows not be part of the goals.
|
|
||
| Listing these here allows the community to get the process for these resources | ||
| started right away. | ||
|
|
There was a problem hiding this comment.
It is part of the template, should we not add the info here or remove this section?
|
This design should also factor in the new ways of a) running an Operator (directly apply an CSV https://jira.coreos.com/browse/OLM-1071) b) creating an Operator bundle (openshift/enhancements#27) |
estroz
changed the title
Description of the change: SDK/OLM integration enhancement proposal
Motivation for the change: expand upon work already done
See #1912 for implementation.
/cc @dmesser @dangeoffroy @joelanford