generate binary-less dockerfiles

[grokspawn]

Description of the change:
provide the capability for opm generate dockerfiles to generate Dockerfiles which build a binary-less catalog image based on scratch.

We expose a new builder-image flag, allowing users to specify a new image to be used as a builder in the multi-stage dockerfile generated. This may not be scratch.
builder-image and binary-image flags both default to quay.io/operator-framework/opm:latest
In order to generate a binary-less catalog image dockerfile, users just need to specify binary-image of scratch.

Users who previously set binary-image may need to check if they need to also specify builder-image to preserve existing behavior

Motivation for the change:
binary-less catalogs can be built on scratch to make tiny, platform-less catalog sources which can leverage the .spec.grpcPodConfig.extractContent fields to allow for on-cluster unpacking.

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.36%. Comparing base (7393a82) to head (ca611d8).
Report is 5 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1338   +/-   ##
=======================================
  Coverage   48.36%   48.36%           
=======================================
  Files         133      133           
  Lines       12693    12693           
=======================================
  Hits         6139     6139           
  Misses       5516     5516           
  Partials     1038     1038           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[grokspawn]

Works against olm at master:latest with something like the following pullspec & spec:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  creationTimestamp: "2024-05-22T18:22:14Z"
  generation: 1
  name: binless-catalog
  namespace: operator-lifecycle-manager
  resourceVersion: "252991"
  uid: 55bd0528-ad19-4aaa-99f5-41677f8726e9
spec:
  displayName: Jaime's Discount Catalog -- Now without bins!
  grpcPodConfig:
    securityContextConfig: restricted
    extractContent:
      cacheDir: /tmp/cache
      catalogDir: /configs
    securityContextConfig: restricted
  image: quay.io/jordankeister/catalogs:v4.14-community-binless
  publisher: OperatorHub.io
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 60m

but requires operator-framework/operator-lifecycle-manager#3270 to function (and this has not been included in a release yet).

[grokspawn]

Generated dockerfile is in the format:

# The builder image is expected to contain
# /bin/opm (with serve subcommand)
FROM quay.io/operator-framework/opm:latest as builder

# Copy FBC root into image at /configs and pre-populate serve cache
ADD configs /configs
RUN ["/bin/opm", "serve", "/configs", "--cache-dir=/tmp/cache", "--cache-only"]

FROM scratch
# OLMv0 CatalogSources that use binary-less images must set:
# spec:
#   grpcPodConfig:
#     extractContent:
#       catalogDir: /configs
#       cacheDir: /tmp/cache

COPY --from=builder /configs /configs
COPY --from=builder /tmp/cache /tmp/cache

# Set FBC-specific label for the location of the FBC root directory
# in the image
LABEL operators.operatorframework.io.index.configs.v1=/configs

[grokspawn]

[grokspawn]

Solves #1349

[grokspawn]

I think this is ready for another round of review

[grokspawn]

Ooh. Found a cleaner way to handle baseImage conditionality. 😄

[joelanford]

You know, I actually prefer baseImage because it makes more sense in the context of using "scratch", but the flag name is binary-image, so I understand this change.

Another option that crossed my mind (which is more complex code, but better end-user UX):

• Deprecate/hide --binary-image
• Add --base-image (and let it take over the shortened -i)
• Make --base-image and --binary-image mutually exclusive.

But then I also thought to myself: "But long-term I still want better tooling that doesn't require users to have to do their own docker builds, so maybe we minimize work and complexity here because [the above suggested changes] don't actually matter all that much."

[grokspawn]

I mean ... me too on the base-image thing, because that's what it is. In this case, it was exposed as binary-image so I just aligned things.
And I had already played with the same kind of thinking w.r.t. mutual-exclusivity and renaming to base-image and it's not much code, so let me push up what I think that looks like.

[grokspawn]

./bin/opm generate dockerfile --binary-image scratch --base-image scratch foo
Flag --binary-image has been deprecated, use --base-image instead
Error: if any flags in the group [binary-image base-image] are set none of the others can be; [base-image binary-image] were all set
Usage:
  opm generate dockerfile <dcRootDir> [flags]

[grokspawn]

Updated in last so that old calling patterns are preserved, for e.g. if caller only uses deprecated binary-image flag, then both base-image and builder-image are inferred from it. The resulting Dockerfile is still multi-stage, but using the same image for both stages.

[joelanford]

Where did we land on adding this?

cmd.MarkFlagsMutuallyExclusive("binary-image", "builder-image")

[grokspawn]

I thought we said that we'd allow mixing them, while complaining.
So someone gives us binary-file and we go "that's deprecated", but we also use it appropriately.
The only special handling is if they use binary-image and nothing else, where we use that value for builder AND base.
But I'm not strongly opinionated on this, so let me know if you are.

[everettraven]

This LGTM
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven, grokspawn

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [grokspawn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment