search

operator-framework / operator-courier

Build, verify and push operators
Apache License 2.0
41 stars 53 forks source link

Add option to save catalogsource aka push-ready-bundle to disk #128

Closed jsm84 closed 5 years ago

jsm84 commented 5 years ago

The Container Verification Pipeline currently uses a configmap-based catalogsource (which contains both a CatalogSource and ConfigMap delimited by --- in a single yaml file) for deploying/testing an operator using OLM. The operator-courier's built-in "push" feature and support for quay.io application namespaces is awesome, but it would also be nice to have a "save to disk" feature in addition to the default functionality of the operator-courier push command.

For our team, this would make it easier for partners to test using the same methods the pipeline uses (that is, leveraging OLM exclusively and not the marketplace). This way a simple oc create -f catalogsource.yaml (and possibly also configmap.yaml) would be essentially all that is needed for partners to test in OLM (not taking into account namespaces, operatorgroups, etc). I plan to implement this on my own, unless someone beats me to it.

kevinrizza commented 5 years ago

@jsm84 We are trying to move away from bundled configmaps entirely in this project (with the goal of deprecating any sort of building of them in a future release) -- if your goal is to create a catalog source directly without using app-registry, the best solution is to build an operator-registry image:

https://github.com/operator-framework/operator-registry#building-a-catalog-of-operators-using-operator-registry

Then just create a CatalogSource with sourceType: grpc and image: $ImageYouJustBuilt:

https://github.com/operator-framework/operator-registry#using-the-catalog-with-operator-lifecycle-manager

My advice is you should do everything you can to not create ConfigMaps if possible, they do not scale well at all. Eventually a single operator that has several updated csv versions will overflow a configmap and it will not work.

jsm84 commented 5 years ago

Thanks @kevinrizza I have notified the CVP team and they've already implemented the fix (moving away from ConfigMaps in the CVP) and are currently testing it. Closing this.