doc(bundles): propose strategy for handling big bundles

[njhale]

Address operator-framework/operator-lifecycle-manager#1523

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

[ecordell]

my guess is that the majority of individual manifests (I have no data, just guessing) will fit within a single configmap. could we reserve the chunking for manifests that don't fit?

Then unpacking a large bundle could look like:

ConfigMap1

• service
• serviceaccount
• rbac

ConfigMap2

• csv
• CRD A

ConfigMap3

• CRD B Part 1

ConfigMap4

• CRD B Part 2

This seems like it will increase the debuggability of bundle unpacking for the common case

[njhale]

If the majority of resource will fit into a single ConfigMap, wouldn't we get something fairly reasonable anyway (with better space utilization)?

e.g.

ConfigMap1:

• service
• serviceaccount
• rbac
• CRD A
• CSV part 1

ConfigMap2:

• CSV part 2
  ...

[ecordell]

That looks good to me - I'm not sure I'm seeing the distinction as writ though.

will the configmap look like

data:
  {service}{serviceaccount}{rbac}{CRDA}{CSVpart1}
---
data:
  {CSVPart2}

or like:

data:
   - {service}
   - {serviceaccount}
   - {rbac}
   - {CRDA}
   - {CSVpart1}
---
data:
  - {CSVPart2}

[njhale]

Ah, I see now. I had envisioned the former, but the latter may be more clear. I do think this will be opaque to most end users, but I see your point.

[jmccormick2001]

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]

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.

[ecordell]

I would leave the size probing as future work - there doesn't seem to be an immediate need, and it may be worth pursuing more direct options (i.e. should this value be exposed as a property of the cluster than anyone can query from kube-apisever?)

[zcahana]

Would it make sense to have the /content subresource accept a filename parameter and return only that specific manifest? If I understand correctly, the catalog-operator consume manifests step by step, so this can avoid some wasteful traffic between the catalog-operator and the aggregated api server serving that subresource.

[njhale]

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

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