FBC: Add properties to olm.package and olm.channel

[cdjohnson]

Problem: There is no simple way to add third-party metadata to File Based Catalogs. The options include:

1. Adding labels to the built catalog image.
2. Adding files to the catalog image
3. Adding custom fields to the catalog yaml

The problem with all three of these approaches is that none of the tooling preserves this additional metadata since it is not part of the Go blob schema for these objects.

Solution:
To solve this, I'd like to see adding Properties to the olm.package and olm.channel blobs, just like the properties format for the olm.bundle blob.

Example:

schema: olm.package
name: foo
defaultChannel: v1
properties:
- type: ibm.epoch
   value: 20220111.223045.00000
- type: ibm.version
   value: 4

Slack conversation history:
https://kubernetes.slack.com/archives/C0181L6JYQ2/p1640821737179600

[joelanford]

There is a fourth option that I just remembered. You can define your own schemas, and opm will preserve them. See: https://github.com/operator-framework/enhancements/blob/master/enhancements/declarative-index-config.md#extension-formats

Regardless, it seems reasonable to add properties to packages and channels. If others agree, I'd also advocate for updating the original EP and the docs website.

[cdjohnson]

@joelanford
I just tested with the 4th option with opm render and it does indeed render the blob and all fields defined in that blob. It implicitly preserves all fields. Is that the intent? At the moment, if I provide any unknown blob schema, then the blob is treated as a default, and the contents of that blob are rendered:

Example: This is completely preserved, and the validator doesn't balk on duplicate schema+name.

---
schema: ibm.package
name: foo
otherProperty: test
properties:
- type: testProperty
  value:
    test: abc
    test1: 123
---
schema: ibm.package
name: foo
otherProperty: test2
properties:
- type: testProperty
  value:
    test: abc
    test1: 123

[joelanford]

It implicitly preserves all fields. Is that the intent?

Yes

This is completely preserved, and the validator doesn't balk on duplicate schema+name.

That's expected. operator-registry defines a Meta schema that is used to parse all blobs. It then further uses the Schema field to re-parse the blobs based on known schemas olm.package, olm.channel, and olm.bundle. Any other schemas are handled mostly opaquely, with two exceptions:

• If a schema contains a properties field, it must be a list of the defined FBC property type.
• If a schema contains a package field, opm will group blobs of that schema with other blobs related to that package. Off the top of my head, I can't think of any place that happens other than opm migrate, which will never deal with extension schemas anyway (since migrate only supports sourcing sqlite-based catalogs, where the concept doesn't exist)

There's no validation, mainly because a custom schema may have a custom set of fields that defines a uniqueness key or there may not be a uniqueness constraint on some schema. As is, any extension schema validation is left up to the schema definer.

[awgreene]

We discussed this issue in the OLM Working Group meeting and have decided to implement it. If anyone has free development cycles please ping me and I will assign the issue to you.