RFE: mirror an index subset based on Subscriptions

[mhrivnak]

I'm seeking initial feedback on this idea and am happy to write up a more formal proposal if it seems like a reasonable direction.

Use case

I am a customer with a disconnected environment. I need to make specific OLM-based operators, which I receive from a vendor and have chosen in advance, available for installation inside my network. I have many clusters inside my disconnected network, and I run my own container registry inside that network.

When managing many clusters, either gitops or some other management approach and tooling will be used to define what Subscriptions exist on which clusters. Assuming I want a specific operator installed on all my clusters, I will define a Subscription for it that references at a minimum:

• package name
• channel
• reference to my customized CatalogSource, which of course is an index image present in my internal container registry.

This Subscription will be stored in a git repo or some other place from which it can be applied to many clusters.

Proposal

Subscriptions can be used as the source of truth for curating a subset of the vendor's index image.

I propose an opm command that will take as input:

• list of Subscriptions, either as yaml files on disk, or piped to stdin
• reference to a vendor's index image

The command will parse the Subscriptions and for each:

• find the head of that package's channel in the vendor's index image
• add that bundle to a new registry db

Perhaps something like this:

opm registry add --from-subscriptions=./ --index=quay.io/somevendor/amazingoperators:latest

The resulting database file should enable me to build an index image that I can mirror with oc adm catalog mirror, and thus provide updates to my disconnected clusters.

single-cluster use

For a small number of clusters, or single cluster, generating an index of updates could be as simple as:

oc get subscriptions -o yaml | opm registry add --from-subscriptions - --index=quay.io/somevendor/amazingoperators:latest

Alternatives

We could make the customer define in a simpler format which operators they want to mirror, avoiding the need to make Subscriptions just to mirror content. That would involve listing pairs of package name and channel, perhaps in an index file of some kind.

But on day 2, when they just want updates, the source of truth for which operators they need to update is their Subscriptions. Even on day 1, in order to install operators, they will need to make Subscriptions anyway. Using a Subscription on day 1 to define desired state enables a series of tooling, including the mirroring of content and creation of Subscriptions in clusters, to make the desired state a reality.

Pros:

• removes the need for opm or other mirroring-related tooling to understand what a Subscription is.

Cons:

• requires the customer to duplicate the same data in both their Subscriptions and their definition of their curated index image.

[ecordell]

This makes a lot of sense, and I agree that we need something along these lines for disconnected customers.

Aside from cli flag bikeshedding (which we can do any time 😄) I just have one comment:

find the head of that package's channel in the vendor's index image

We want to find all of the intermediates in the subscribed channel in between the currently installed operator (luckily, this is also on the subscription) and the head of that channel. Grabbing just the head will only work if the package is consistently using the skipRange feature for the channel head.

@dmesser may want to weigh in here as well

[mhrivnak]

We want to find all of the intermediates in the subscribed channel in between the currently installed operator (luckily, this is also on the subscription) and the head of that channel. Grabbing just the head will only work if the package is consistently using the skipRange feature for the channel head.

Good point. We can add a flag --lets-go-ahead-and-grab-all-the-intermediate-releases-since= 😉, ok we can probably find a better name for that one.

AIUI, the downside of including more releases from a channel is that you'll later end up mirroring more container images for both the operator and operands, so that could add up to a lot of data being transferred and stored. What do you think about defaulting to just the head, since many vendors will be following our advice of using skipRange, and then add a --since option? That could later be enhanced by some kind of --prune option that understands the resulting graph and excludes releases that can be skipped.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dmesser]

Pruning and filtering based on blacklisting/whitelisting has been implemented in opm via #243.
Closing this in favor of #243