-
Notifications
You must be signed in to change notification settings - Fork 50
Improve the local source type #464
Description
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:
- It limits the size of a bundle to the maximum etcd value size (minus overhead), which can be as little as 1MB
- 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
toconfigmaps
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.