document bundle metadata format troubleshooting #121
Conversation
Signed-off-by: Jordan Keister <[email protected]>
|
|
||
| == Bundle properties are not permitted in a FBC fragment for OCP version | ||
|
|
||
| Tasks may fail with an error message containing the string `bundle properties are not permitted in a FBC fragment for OCP version`. This means that your fragment needs to utilize the appropriate FBC bundle metadata format which aligns with your target catalog. Failure to do so will not display your package in the OpenShift WebUI properly. |
There was a problem hiding this comment.
| Tasks may fail with an error message containing the string `bundle properties are not permitted in a FBC fragment for OCP version`. This means that your fragment needs to utilize the appropriate FBC bundle metadata format which aligns with your target catalog. Failure to do so will not display your package in the OpenShift WebUI properly. | |
| Tasks may fail with an error message containing the string `bundle properties are not permitted in a FBC fragment for OCP version`. This means that your fragment needs to utilize the appropriate FBC bundle metadata format which aligns with your target catalog. Failure to do so will result in your package not being displayed in the OpenShift Console. |
| === If you use other tooling to generate your fragment | ||
|
|
||
| If you rely on other tooling/processes to produce your fragment and currently use the `olm.bundle.object` bundle metadata format, then you may either adjust your tooling to align your bundle metadata format with the target OCP version or you may use `opm` to migrate your fragment's bundle metadata by using `opm render --migrate-level=bundle-object-to-csv-metadata [fragment-ref]` (where `fragment-ref` is a pullspec to the fragment or a path to a directory containing the fragment). | ||
| Please note that this process is lossy, so it only works when converting `olm.bundle.object` to `olm.csv.metadata` formats. |
There was a problem hiding this comment.
Please note that this process is lossy, so it only works when converting
olm.bundle.objecttoolm.csv.metadataformats.
I'm having trouble grokking this sentence and understanding how it applies to this section and not the other.
I know that this migration is lossy and how it is lossy, but users probably won't unless we explain the details. Non-CSV object properties are dropped and the CSV property is reduced to what is in the olm.csv.metadata API. Maybe we should explain that detail so users can understand the implications of what is being lost? (e.g. if their QE may be depending on olm.bundle.object for something)
| @@ -149,3 +149,23 @@ kubectl get secrets -o json | | |||
| {auths: .} | |||
| ' | |||
| ---- | |||
|
|
|||
|
|
|||
| == Bundle properties are not permitted in a FBC fragment for OCP version | |||
There was a problem hiding this comment.
I assume there will be a way to directly link to this header from our error message?
Related: is there a way to avoid (or at least reduce the chances of accidentally breaking that link (e.g. if we change the header text)?
There was a problem hiding this comment.
As I mentioned in konflux-ci/build-definitions#1327 (comment), can we move this to a TROUBELSHOOTHING.md file in the task directory within build-definitions? We can then link directly to the build-definitions repo troubleshooting as needed from the task.
I'm clear on transplanting all of this to a TROUBLESHOOTING.md file that is co-resident with the task definitions. I'm not clear on what kind of reference you would like here? Or if there would be any. One reading of your last sentence would be to close/abandon this PR and embed all the docs/references in the task area. Can you clarify, @arewm ? |
|
I don't think that we need any references in this document. We need to work to merge the task documentation, usage, and troubleshooting into the rendered konflux-ci documentation. When we do that, we should get anything added there for "free." |
|
Thanks for the detail. |
Documenting troubleshooting for the new bundle metadata policy enforcement, aligned with target OCP versions.
The intent is to use this doc as a reference that we'll cite as part of the failure messaging related to the policy task (konflux-ci/build-definitions#1327).