[RFE] Declarative OPM config

[kevinrizza]

Feature Request

Is your feature request related to a problem? Please describe. As an operator pipeline administrator, I would like to have more fine control over exactly what is included in an index image.

Why is this important: Index images currently are only built via metadata included in bundle images to define and modify package level updates, as well as to define what versions are included in the package. Because the only trivial way of including more data is to append to the front of a package, if something needs to be modified, updated or removed there is no easy way to do that today.

Describe the solution you'd like

• A user can inspect an existing index image to determine what package versions are available as well as any other metadata associated with the package or the index as a whole
• A user can modify package and index level metadata to redefine the content that is in the index

Current work in progress: https://github.com/operator-framework/enhancements/pull/37

[Jamstah]

I know this is going back to the core of this, but I'd like to bring it up:

Do we need to be designing this in a way that can work with existing index images, or is it enough to design something that can create new index images declaratively?

If we don't need to work with existing indexes, we don't need to worry about generating a declarative config from existing index databases, and instead, can just define a structure to be able to build.

This thought partly comes from considering the buildah approach to doing this. We can already create a declarative(ish) config for index images by writing a bash script for generating the index using a sequence of opm index commands.

This covers a lot of the use cases we have:

• We can go back and change how bundles were added (channels etc)
• We can take bundles out of the catalog entirely
• We can split the script into packages so that they are easy to break apart/join together

From the current goals:

1. Allow for validation of an index against a standard definition of an index (possibly using a data definition language) - It wouldn't cover this, but I feel there are easier approaches to this goal
2. Provide a way for index authors to reason about their indexes via a visual representation of the index, without having to curl a grpc api that in turn queries a sqllite database underneath etc - It wouldn't cover this, but would help remove the need to do it
3. Provide a way for tools like opm, operator-registry etc to consume the representation of an index instead of needing a sqlite database as an input whenever they need information about the index to perform a task. It would remove the need for this
4. Allow for reproducability of an index using just the yaml/json representation Reproducability would be covered

It wouldn't be as complete a solution, but it would cover a lot of the goals with very little effort:

• We would need to document the approach and recommend that people use it to manage their catalog indexes

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dinhxuanvu]

This feature has been completed as it is in the current codebase. /close

[openshift-ci[bot]]

@dinhxuanvu: Closing this issue.

In response to this:

This feature has been completed as it is in the current codebase. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kevinrizza]

this is very out of date. closing