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
As a follow up to #39, configure the aggregated apiservice to store the objects in a custom storage, so that the main etcd storage is not misused for storing the resources created by the catalog controller.
cc: @joelanford I know you had some opinions about which storage is better suited for our use case, considering atomic availability of content from a catalog during creation/re-sync etc.
Also, initial thought is that it'll be cleaner to have this storage running in a separate pod, that the aggregated apiservice connects to using api endpoints, so that the apiservice process isn't also responsible for running the db in memory. That way, if the process running the db is unavailable for any reason (eg exceeded memory limits and therefore is getting kicked out by the main apiservice), the running aggregated apiservice is still available to communicate to clients that the storage is unavailable. This also off loads risks related to aggregated apiservice unavailability (I.e potential domino effects to the main apiservice)
Motivation:
As a follow up to #39, configure the aggregated apiservice to store the objects in a custom storage, so that the main etcd storage is not misused for storing the resources created by the catalog controller.
Some potential options:
The text was updated successfully, but these errors were encountered: