search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

doc(bundles): propose strategy for handling big bundles #40

Closed njhale closed 3 years ago

njhale commented 4 years ago

Address https://github.com/operator-framework/operator-lifecycle-manager/issues/1523

To ensure Operator Bundles of arbitrary size can be unpacked and used in a Kubernetes cluster by OLM, we can ...

jmccormick2001 commented 4 years ago

https://etcd.io/docs/v3.4.0/dev-guide/limit/

that shows a request limit of 1.5Mb with a --max-request-bytes flag to allow for a larger request limit...was wondering about your thoughts of just leveraging this etcd feature or if that is not possible?

njhale commented 4 years ago

https://etcd.io/docs/v3.4.0/dev-guide/limit/

that shows a request limit of 1.5Mb with a --max-request-bytes flag to allow for a larger request limit...was wondering about your thoughts of just leveraging this etcd feature or if that is not possible?

@jmccormick2001 that's something we've considered in earlier discussions.

AFAIK, changing the storage limit for a cluster's etcd is a highly privileged (and possibly disruptive?) task -- further, we would need to bump this value whenever we unpackage a bundle larger than the current limit. So, while I do think that successively large bundles will be a rarity, I would prefer a solution that would avoid perturbing etcd directly.

njhale commented 3 years ago

I think @zcahana's Gzip PR scratches the immediate itch (thanks!).

I'm going to close this out in favor of work in rukpak.