Options for serverless catalogs

[dkrasins]

Please see oracle-cne/ocne#27

There are clearly some issues with using a catalog on the local filesystem. One is that we would need to keep a cache of catalogs on the local filesystem. Also, the catalog would not be present in the cluster, making some interactions in the UI awkward to impossible. There are two approaches that I've been kicking around that might address those concerns.

Option 1) A ConfigMap catalog

The basic idea here is to have a wad of configmaps, with a primary configmap that contains the index.yaml. It would look something like this:

# Add the catalog
$ ocne catalog add --name mycatalog --namespace mycatalognamespace --uri kubernetes:/v1/ConfigMap/mycatalog --protocol configmap

# Sample layout
$ kubectl -n mycatalognamespace get configmap mycatalog -o yaml
apiVersion: v1
kind: ConfigMap
data:
  index.yaml: |
    apiVersion: v1
    entries:
      bootstrap-capi:
      - apiVersion: v2
        appVersion: 1.9.4
        created: "2025-03-13T16:57:06.657284852Z"
        description: A Helm chart for Cluster API bootstrap providers
        digest: 71bf539ed63e834e7b0ef902f4510cfd7689670da89b3282da73579743ca2b7a
        icon: icons/capi.svg
        kubeVersion: '>= 1.30.0 < 1.32.0'
        name: bootstrap-capi
        type: application
        urls:
        - bootstrap-capi-1.9.4.tgz
        version: 1.9.4
      - apiVersion: v2
        appVersion: 1.7.1
        created: "2025-03-13T16:57:06.654572063Z"
    ...

$ kubectl -n mycatalognamespace get configmap bootstrap-capi -o yaml
apiVersion: v1
kind: ConfigMap
data:
  1.9.4: <base64 encoded chart tarball>

Option 2) ocne application install --catalog file --name <uri>

This is a common Helm-ism. The [CHART] field in helm install ... can contain a chart name or something URI-ish.With this approach, there isn't actually a catalog associated with the chart. None of the ocne catalog subcommands will work. The advantage of this approach is that it keeps the user interaction simple, as it prevents having to create a catalog in the cluster, while also preventing us from having to cache anything.Thoughts?

[pfmackin]

For option 2, if this is just a helm chart then I would prefer to use --chart vs --catalog. If i understand this option, there is no catalog involved.

[dkrasins]

We could just skip the --catalog argument entirely, like Helm does. If the application name looks sufficiently URI-like, treat it that way. Nobody is going to name their application /home/dkrasins/charts/myapp or whatever.

[pfmackin]

For option 1, where would the chart be located (e.g. bootstrap-capi-1.9.4.tgz) ?

[dkrasins]

In the little snippet I had above, it was stored as a configmap in the same namespace. The name of the configmap is the application, the keys are the version, and the value is the corresponding tarball. It was just an off the cuff idea.