HIP-0019: Split manifest with Secrets storage driver #284
Conversation
Signed-off-by: Louis Cabrol <[email protected]>
Signed-off-by: Louis Cabrol <[email protected]>
lelithium
force-pushed
the
lcabrol/split-manifest
branch
from
3e779ce
to
40c8a7e
Compare
|
+1 for such a feature See also #256 |
|
|
||
| For Secrets, marking the Secrets with `helm.sh/partial.v1` for partial elements means identifying releases still only relies on the presence of secrets that are named after this format `sh.helm.release.v1.<release name>.v<version>` with the `helm.sh/release.v1` type. | ||
|
|
||
| Older versions of Helm would not be able to interact with the new split manifests in most cases. |
There was a problem hiding this comment.
Older versions of Helm failing to be able to interact with the release is fine in itself I think.
But, not sure if it would be okay to enable the split/partial manifests by default. We need to try hard to account for all scenarios. And it is possible that user might install/upgrade with a new version of Helm, then attempt to interact with that release with an older version. If we have split the manifest by default, they would be broken.
OTOH, it (to me) is completely fine if a user "opts-in" to split manifests. Then it is on them to ensure their processed only use a new enough Helm version
There was a problem hiding this comment.
Hey @gjenkins8, thanks for the review !
An opt-in feature gate make sense for sure.
According to https://kubernetes.io/docs/concepts/configuration/secret/#restriction-data-size this max size is always 1Mib, and we know the size of the manifest to store before applying, so the behavior could be
- If not opted-in, releases larger than the max Secret size should error out early instead of at apply time
- This error could mention the split manifest opt-in
- If opted-in, they're split using the split manifest feature
HIP for a split manifest support for larger-than-1MiB manifests.
Also fixes a link to HIP-0018 in README