"CatalogSourceBundle" API for Wrapping "Bundle of Bundles"

[tylerslaton]

In a recent working group meeting, we began discussing a Deppy-like component (outlined here) which would be responsible for handling resolving catalogs for Rukpak. During the discussion it was mentioned that we may start to look at Rukpak catalogs to be a Bundle of Bundles that would then get resolved like normal by a provisioner. However, the point was brought up that this may be confusing for a user as they are sourcing a catalog using the Bundle API. I was thinking on this issue and wanted to see what we thought about this idea.

What if we added two new core Rukpak CRDs, CatalogSourceBundle and CatalogSourceBundleInstance (name subject to change), to the core Rukpak CRDs?

Essentially this would be an implementation of a Bundle interface where they share similar properties but are named differently (and could include other catalog specific metadata)?. The CatalogSourceBundleInstance could act as a Subscription does today and allow for things like constraints, metadata, etc. As a result, users can now use two separate API's but under-the-hood the resources operate extremely similarly and share the same provisioner-style of resolution.

I envision this looking something along these lines:

apiVersion: core.rukpak.io/v1alpha1
kind: CatalogSourceBundle
metadata:
  name: my-catalog
spec:
  source:
    type: image # Could add a new source of file to read FBC's directly
    image:
      ref: my-bundle@sha256:xyz123
  provisionerClassName: core.rukpak.io/plain-catalog

With a CatalogSourceBundleInstance looking like:

apiVersion: core.rukpak.io/v1alpha1
kind: CatalogSourceBundleInstance
metadata:
  name: my-catalog-source
spec:
  bundleName: my-bundle
  version: v0.0.1 # Example of metadata we could add
  provisionerClassName: core.rukpak.io/plain-catalog

This would result in a BundleInstance (potentially with an embedded Bundle for the resolved catalog item) being unpacked/instantiated on the cluster.

[exdx]

I'm not sure about introducing a new API to describe a type of Bundle, since the original intention of the Bundle/BI API was to be extensible and flexible enough to support different content sources. There are other projects that take the "each content source is its own CRD" approach (for example flux, with a HelmChart type, a GitRepository type, etc) but rukpak was designed intentionally to not take this approach.

I like the idea of using a custom catalog provisioner to "unpack" catalogs and serve them on the cluster. I think this can be achieved without any new APIs though.

[tylerslaton]

That's fair, I think the overall effect is the same and this new API is not required. The intent behind them is to give the user an abstraction so that they know they're making a Bundle and to keep it separate. That being said though, you're right this could be done via the standard API's.

[joelanford]

I'm still pretty unconvinced that a Bundle variant is the right API for a catalog. I can squint and see how you might be able to force fit the catalog concept into a Bundle.

• We write a new provisioner (e.g. core.rukpak.io/file-based-catalog)
• When a Bundle uses the FBC provisioner name, we can pull that FBC from an image or a git repo
• When a BundleInstance uses the FBC provisioner name, we effectively generate a set of plain manifests that result in that FBC being served to the cluster along with something that tells the cluster "hey look over here for a catalog connection"

But does the BundleInstance concept even make sense? We could also just stop at the Bundle and then let consumers of the catalog read the unpacked catalog contents directly (somehow?)

How would consumers find catalogs? Would they need to look at all Bundles and filter by spec.provisionerClassName? Once they found the catalogs, what mechanism would they use to actually access the underlying data? Is there some sort of protocol negotiation? If so, would there need to be something in the Bundle API to facilitate that (if so that seems like a non-starter)? Or would consumers have to be coded to handle specific catalog provisioners?

[perdasilva]

A few things that are in my head atm:

• I'm weary of the Input API being the entry point for installation. Unless the UX is really clear and straight forward. Which, for a constraints engine I'm not sure it's doable. I wonder if we'll need a frontend API to smooth out the UX.
• Can Deppy provide value outside RukPak? If so, would it behove us to have a some sort of client interface that defines the Catalog input to Deppy that is content agnostic but serves up all the inputs required: i.e. properties and constraints. That way we separate the concerns of catalog and Deppy. For Deppy a catalog is anything that implements the defined interface.
• Thinking more about it, alternatively we could say Deppy resolves RukPak Bundle content. Since a Bundle can be anything - we can provide those degrees of freedom for the user that way.
• I think we need to rethink the name Input. It's too generic. Though we can revisit this once we pin down the API.
• Should Deppy care about cluster state? Or only what is defined in the input(s)?
• Should the Input API be a singleton? I like the idea of it not being one. Gives people a chance to run what ifs.
• Does Deppy's output have side effects? E.g. does it drop a ResolverSet Bundle that's picked up by the provisioner? Or does it post the current resolution to the input status and something else does the translation?
• If we want Deppy to use RukPak, should it know/care about the different provisioners that are installed on the system? As a way to ignore certain bundles, or will errors pop up downstream?

[perdasilva]

Sorry, these were general Deppy questions. While I was reading the issue all these things popped up. Should I move this to somewhere else?

[timflannagan]

I'm not sure we have a general place for deppy related questions. It looks like https://github.com/operator-framework/deppy has already been created?