Automate CSV generation

[guymguym]

Continue here the discussion started on PR #33 with @davidvossel.

[davidvossel]

from PR #33

How does OCS operator plan to generate the CSV?

1. run operator-sdk olm-catalog gen-csv to generate the base ocs-operator csv.
2. extract CSV and CRD manifests from the exact noobaa/rook operator container images that ocs-operator is integrating with
3. Merge noobaa/rook operator related manifests into the base ocs-operator manifests.
4. the result is the unified CSV and list of CRDs.

For step 2 to work, we need both noobaa and rook to maintain accurate CSV/CRD manifests within the operator container image for us to extract.

This means for ocs-operator integration, we're less interested in retrieving a pre-bulit release manifest that represents a previous noobaa release, and more interested in retrieving a CSV that is built to reflect exactly what RBAC/Deployment/CRDs correspond to the specific build that's being consumed.

^ That's why my initial PR, #32 generated the template in the built step.

[guymguym]

Hi @davidvossel

1. run operator-sdk olm-catalog gen-csv to generate the base ocs-operator csv.

Is step 1 a repeatable build step? Did you think on how to handle all all those manual CSV properties that are not generated?

For step 2 to work, we need both noobaa and rook to maintain accurate CSV/CRD manifests within the operator container image for us to extract.

So this is already done in #33 right? The CSV and CRD's are part of the container image and can be extracted upon request.

This means for ocs-operator integration, we're less interested in retrieving a pre-bulit release manifest that represents a previous noobaa release, and more interested in retrieving a CSV that is built to reflect exactly what RBAC/Deployment/CRDs correspond to the specific build that's being consumed. That's why my initial PR, #32 generated the template in the built step.

To make sure I understand what you mean - once we automate the CSV generation of the noobaa operator in the build, just like we do for CRD's today (make gen-api), is that what you're interested in?

Thanks!

[davidvossel]

To make sure I understand what you mean - once we automate the CSV generation of the noobaa operator in the build, just like we do for CRD's today (make gen-api), is that what you're interested in?

yes, for our purposes (integration with ocs-operator) the CSV generation should occur at nooba operator build time. This ensures any changes to the noobaa's Deployment/RBAC will be picked up by the ocs-operator when generating the unified CSV.

[davidvossel]

Is step 1 a repeatable build step? Did you think on how to handle all all those manual CSV properties that are not generated?

right, so you're talking about the fields marked as (user) in this doc https://github.com/operator-framework/operator-sdk/blob/master/doc/user/olm-catalog/generating-a-csv.md#csv-fields

There are a few options.

• Create a golang tool to read in the generated CSV file into a struct, add your user bits to the struct, then export the struct as yaml. here's an example of reading in CSV into a struct and exporting it back to yaml.
• Tools like yq could be used to merge those fields into the generated CSV yaml
• some sort of sed/bash logic to splice together the generated CSV along with the custom user defined bits.