Skip to content
This repository was archived by the owner on Aug 12, 2024. It is now read-only.
This repository was archived by the owner on Aug 12, 2024. It is now read-only.

Improve the local source type #464

@joelanford

Description

@joelanford

Getting a simple source implementation in place to support local bundle content is a major quality of life improvement from the current local source that uses a configmap to store bundle contents. However, this implementation has two major drawbacks:

  1. It limits the size of a bundle to the maximum etcd value size (minus overhead), which can be as little as 1MB
  2. It currently only supports plain manifest bundles because configmaps don't directly support directory hierarchies.

To improve the local source type, while still enabling the flexibility of storing bundle contents in configmaps, I would propose a few updates:

  • rename local to configmaps to make it clear that the backing storage is based on the configmap API
  • remove the configmap namespace from the API (i.e. require that bundle configmaps are sourced from the rukpak system namespace). This solves a scaling problem in that provisioners won't have to watch all configmaps in the cluster.
  • change the API to accept multiple configmaps, where each configmap represents a directory within the bundle. Each referenced configmap would include the directory where the configmap should be "mounted" and the name of the configmap
  • Improve the immutability story of this source (e.g. require that referenced configmaps have immutable: true, don't allow configmaps to be deleted if they are referenced by a bundle).

This solution improves on item 1 above in that it effectively changes the bundle size maximum from "1MB for the entire bundle" to "1MB for each file in the bundle". It's still not quite as good as the solution proposed in #472, but it will be a vast improvement over the current local limitation.

This solution completely solves 2 because it enables arbitrary directory hierarchies to be described in the API.

Metadata

Metadata

Assignees

Labels

lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions