operator-sdk-builds-catalogs: catalog builds in operator-sdk

[estroz]

This enhancement proposes an addition to operator-sdk-built projects that enables users to build catalogs in a straightforward, low-effort manner.

Reference PR: operator-framework/operator-sdk#4406

Signed-off-by: Eric Stroczynski ericstroczynski@gmail.com

[estroz]

/cc @jmrodri @tlwu2013

[jmrodri]

A question, a couple minor change requests.

[jmrodri]

I like this change, but would it be considered a breaking change?

[estroz]

Nope, this is just a convenience thing.

[jmrodri]

I would make sure we comment each of these targets. I think Camila recently did a PR adding comments to various parts of the generated makefiles.

[estroz]

I agree this is important. My POC PR has a bunch of Makefile comments.

[jmrodri]

Question:
If I want to use an existing catalog image I assume I could just do:

make catalog-build CATALOG_IMG=quay.io/me/my-image-with-deps:dev

And then we will add our bundle to that existing image.

[estroz]

There's actually another flag --from-index you'd use to build from an existing index image. Since the base image doesn't actually exist anywhere (opm index add builds it for you), I've opted not to include this flag. Perhaps a Makefile comment about this flag would be useful.

[kevinrizza]

I'm not sure I understand this comment @estroz , --from-index is for cumulative builds. It allows you to add a single bundle to an existing index by pulling the old index down, pulling the content onto local disk, appending to it, and then building a new index without having to pull all the bundles every time you just want to update your existing set. Are we saying that the usecase for the sdk expects their users to keep historical record of all previous bundle images locally?

[tlwu2013]

Are we saying that the usecase for the sdk expects their users to keep historical record of all previous bundle images locally?

I don't think "keep a historical record of all previous bundle images locally" is a requirement. Hence, it's better to allow users to add a new bundle image (and potentially its dependencies from other Operators) to an existing catalog.

[estroz]

--from-index is for cumulative builds

That's what I intend users to do.

Are we saying that the usecase for the sdk expects their users to keep historical record of all previous bundle images locally

Definitely not, that's what git is for.

[kevinrizza]

I'm just trying to point out that --from-index is a pretty core piece of functionality that we expect all of our opm users to be using aside from the first time they publish an index. It seems odd to differ that fundamentally from how most folks are using the tool now. Or maybe I'm just totally misreading this?

[estroz]

Its more a problem of defaults than differentiating behavior. There is no default image to set --from-index to when a project is created such that I can run make catalog-build without opm index add failing. The user has to build an index image containing one bundle first, and only then can they add --from-index to the catalog-build recipe one they're ready to add another bundle to the existing index. That's why I suggest we add a comment about this.

[tlwu2013]

+1 on the rationale going with "a Makefile rule" vs "a subcommand".
Thanks for pointing that out!

Also left one comment regarding 'allowing users to add "a new bundle + its dependencies" to an existing catalog'.

Another thought:
Since "adding bundles/dependencies to an existing catalog" aspect is important for this epic, it might be great to also allow users to "remove packages/dependencies" from the catalog (also supporting "opm index prune"?) in case they need to edit/change the dependencies or simply need to revert a mistake.

What do you think?

[tlwu2013]

Are we saying that the usecase for the sdk expects their users to keep historical record of all previous bundle images locally?

I don't think "keep a historical record of all previous bundle images locally" is a requirement. Hence, it's better to allow users to add a new bundle image (and potentially its dependencies from other Operators) to an existing catalog.

[estroz]

it might be great to also allow users to "remove packages/dependencies" from the catalog (also supporting "opm index prune"?

@tlwu2013 perhaps this would be useful to some devs, but I expect that number to be much smaller than those using opm index add for the sole reason of scope: index prune removes entire packages from an index (multi-operator scope) while index add adds one operator to an index (single-operator scope). If you're using index prune you are likely a power user (as described in the enhancement) and not just working with one project, hence it doesn't make sense to wrap that command in a project's Makefile. Correct me if I'm wrong about how index prune works.

[tlwu2013]

Thanks for adding examples for adding bundles + adding dependencies. Looks good to me!