You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Catalog images are exclusively container images hosted in image registries today. There's growing evidence to suggest that allowing catalog content to be packaged and published in other ways (such as as OCI images, or in git repositories, or even added to the cluster as configmaps) could streamline the process of building and maintaining these clusters, improving quality of life for catalog authors.
Introducing a new field spec.Source in the CatalogSource CRD, and adding the value image that calls the unpacking job that exists today, will lay the ground work for introducing new spec.Source type in the near term.
The text was updated successfully, but these errors were encountered:
Look into extracting the source API and implementation to a common place
Look into actually depending on rukpak APIs and treat catalogs as a type of Bundle (e.g. using a different provisioner class)
Look into improvements in the source.Result API which contains what could end up being a very large in-memory fs.FS when we start thinking of catalogs as bundles (perhaps io.ReadCloser is a better interface to use at that layer?).
Catalog images are exclusively container images hosted in image registries today. There's growing evidence to suggest that allowing catalog content to be packaged and published in other ways (such as as OCI images, or in git repositories, or even added to the cluster as configmaps) could streamline the process of building and maintaining these clusters, improving quality of life for catalog authors.
Introducing a new field spec.Source in the CatalogSource CRD, and adding the value
image
that calls the unpacking job that exists today, will lay the ground work for introducing new spec.Source type in the near term.The text was updated successfully, but these errors were encountered: