The OLM v0 CatalogSource architecture has been a source of high resource consumption (both CPU and memory) over a considerable period of time now. The implementation worked well when the underlying storage used on-cluster for storing catalog content pulled from the internet was a sqlite db. With new storage mechanisms (eg FBC) replacing the old sqlite db, porting over a heavy weight implementation that consumes extra resources makes little sense.
To ensure users can consume operator catalogs on cluster with the OLM v1 architecture, we'll need to refine/redefine how on-cluster CatalogSource is implemented in the v1 world.
anik120
commented
1 year ago
Goal:
The OLM v0 CatalogSource architecture has been a source of high resource consumption (both CPU and memory) over a considerable period of time now. The implementation worked well when the underlying storage used on-cluster for storing catalog content pulled from the internet was a sqlite db. With new storage mechanisms (eg FBC) replacing the old sqlite db, porting over a heavy weight implementation that consumes extra resources makes little sense.
To ensure users can consume operator catalogs on cluster with the OLM v1 architecture, we'll need to refine/redefine how on-cluster CatalogSource is implemented in the v1 world.
Current In progress work:
Current proposed work: