Operator-sdk: Add CSV fields expected by various validator tools

Created on 16 Oct 2019  路  6Comments  路  Source: operator-framework/operator-sdk

Feature Request

Is your feature request related to a problem? Please describe.
Here are some fields in the CSV I've documented having to edit in my CSV after running gen-csv. These are all things I've found required by tools like operator-courier validate and scorecard or I received complaints about when pushing the CSV into OpenShift.

  • spec.keywords
  • spec.maintainers
  • spec.provider
  • metadata.namespace
  • spec.icon (base64 encoded image embedded in the yaml)
  • spec.customresourcedefinitions
  • spec.customresourcedefinitions.owned.[description, displayName, kind, name, version, resources]

Describe the solution you'd like
I expect that spec.[keywords,maintainers,provider] could be configured through the use of a field in deploy/olm-catalog/csv-config.yaml.

Currently, spec.customresourcedefinitions aren't included at all. I expect that information to be pulled from the CRD where available. Perhaps a placeholder should be put into the CRD when generated like other fields experience.

Absence of spec.icon throws a warning in some validators so maybe a warning here would be appropriate with a document on how to create such an icon. Also, I always move this to the bottom of the CSV for convenience since vim displays it awkwardly due to the length of the line.

good first issue kinfeature olm-integration

All 6 comments

Hi @flickerfly,

Thank you for getting in contact. Following the detailed info.

spec.customresourcedefinitions
spec.customresourcedefinitions.owned.[description, displayName, kind, name, version, resources]

It will get done when this PR https://github.com/operator-framework/operator-sdk/pull/1162 be merged, then, it is a duplication of #1132.

So, we could keep this taks as an RFE for the operator-sdk olm-catalogue generated the following ones.

spec.keywords:
spec.maintainers:
spec.provider:
namespace: placeholder
spec.icon:

Oh, excellent! Thanks for the pointers to other issues/PRs. I'll keep an eye on them also.

Hi @flickerfly,

Also, I'd like to share that I tested it now with the 0.11.0 and the metadata.namespace has been generated which means that this issue here would be kept just for the following ones.

spec.keywords:
spec.maintainers:
spec.provider:
spec.icon:

Hi @flickerfly,

The above fields are not mandatory for the operator to work in OLM. However, you will probably check some errors/warnings when the operator-courier verifies the CSV if they are not present since they are recommended to publish the project in the OperatorHub.io and/or OCP catalogue.

Note that these values cannot be obtained in the code source of the project and to populated it as you requested here, would be required to use placeholders however, after a big discussion was defined that it would not be the best approach and could lead the users to believe that the CSV is correctly populated when it is not.

Note that in order to help its users, a WARN as follows appears when the CSV is generated currently.

$ operator-sdk olm-catalog gen-csv --csv-version 0.0.1
INFO[0000] Generating CSV manifest version 0.0.1
INFO[0000] Required csv fields not filled in file deploy/olm-catalog/app-operator/0.0.1/app-operator.v0.0.1.clusterserviceversion.yaml:
spec.keywords
spec.maintainers
spec.provider
INFO[0000] Created deploy/olm-catalog/app-operator/0.0.1/app-operator.v0.0.1.clusterserviceversion.yaml

However, the project has other plans in place to try to improve the user experience and make this process easier, for example, by implementing a new API lib to validate it. See https://github.com/operator-framework/api.

Then, because of this, was decided not to move forward with it. So, I hope that you are ok with close to this one. However, please feel free to re-open with you think that still required.

Thanks, I'll watch that space. Sounds like you heard what I was thinking and have plans to deal with it another way.

Sure, really thank you for your collaboration and understanding. We definitely heard and completed understanding your motivation here and we will work to improve this. It just will be done in another way according to some strategy in places.

Was this page helpful?
0 / 5 - 0 ratings