generate csv: support manifests/ format with --make-manifests

[estroz]

Description of the change: generate csv --make-manifests will generate a manifests/ directory at <deploy-dir>/olm-catalog/<operator-name/manifests or, if --output-dir is set, <output-dir>/manifests. Previous behavior is the same, except setting --output-dir will direct the generator to check if a CSV bundle exists in the output directory before checking the default <deploy-dir>/olm-catalog/<operator-name> directory.

hack/tests: add generate csv subcommand tests that check behavior and not content of generated files (this is done in unit tests)

Motivation for the change: The new manifests/metadata format is supported by operator-sdk bundle create. generate csv should align in a backwards-compatible way so operator authors can choose between versioning their bundles on disk vs. in VCS. --make-manifests=true by default, so to get previous behavior you must set --make-manifests=false. The only other change to previous behavior, checking the output dir for bundles first, ensures you do not have to maintain both a default bundle location and an output directory.

Relates to #2746

/kind feature

[jmccormick2001]

changelog?

[estroz]

Most changes to this file are cosmetic except for setting bundleGenerator.noUpdate, which prevents the generator from reading a CSV to update from so we can check a newly-generated CSV against the expected CSV in testdata.

[dmesser]

What do you think about aggregating generating the CSV with generating the bundle? Both are really only useful when they appear together.

On Fri 3. Apr 2020 at 22:30, Eric Stroczynski ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In internal/generate/olm-catalog/csv_go_test.go <#2776 (comment)> : > @@ -16,16 +16,14 @@ package olmcatalog Most changes to this file are cosmetic except for setting bundleGenerator.noUpdate, which prevents the generator from reading a CSV to update from so we can check a newly-generated CSV against the expected CSV in testdata. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#2776 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAT2NP7EFM6JBBFJB57KX3RKZBNJANCNFSM4L4KJEWA> .

--

[estroz]

@dmesser totally possible and is amenable to a followup. That's effectively the same as:

$ operator-sdk generate csv --csv-version 0.1.0 --make-manifests \
	--output-dir /tmp/foo
$ operator-sdk bundle create quay.io/example/memcached-operator:v0.1.0 \
	--directory /tmp/foo/manifests
$ rm -rf /tmp/foo

If we can eventually persist all UI-centric information to disk, ex. in a config file + doc.go files, CSV generation can be completely in-memory.

[dmesser]

@estroz For the sake of simplicity, could we not imagine bundle create being capable of doing both in one step? e.g.

operator-sdk bundle create --version 0.1.0

which creates the bundle layout, annotaitons and CSV metadata on disk (in a default directory or specified by --directory). Followed-up by a:

operator-sdk bundle build quay.io/example/memcached-operator:v0.1.0

which is equivalent to

podman build -f bundle/Dockerfile bundle/

to support pipelines without daemons.

[joelanford]

For the sake of simplicity, could we not imagine bundle create being capable of doing both in one step?

We've been own that road with operator-sdk build (see #1600). Makefile is a great way to solve this. For example:

BUNDLE_IMAGE="quay.io/example/test-operator-bundle"
OPERATOR_VERSION="v0.1.0"

.PHONY: csv bundle-image bundle-push scorecard

csv: manifests # manifests target generates CRDs, roles, etc.
	operator-sdk generate csv --version=${OPERATOR_VERSION} --make-manifests

bundle-image: csv
	operator-sdk bundle create ${BUNDLE_IMAGE}:${OPERATOR_VERSION} \
		--directory ./deploy/olm-catalog/test-operator

bundle-push: bundle-image
	docker push ${BUNDLE_IMAGE}:${OPERATOR_VERSION}

scorecard: bundle-image
	operator-sdk scorecard --bundle=${BUNDLE_IMAGE}:${OPERATOR_VERSION}

Run make bundle-push and you're done :)

We would theoretically be able to inject extra targets into the Makefile generation of operator-sdk init to give users the "best practice" make targets for OLM integration, but then users could tweak to their heart's content without us having to support every conceivable tweak to the workflow.

I think this would also help us focus more on the UX of the individual commands, which would ideally be simple on their own AND be able to be composed into really powerful workflows.