Put support for v1 secret format behind feature flag #235
Conversation
|
Please add a note to README.md, with recommended handling for those who possible still carry v1 sealedsecrets on how to move them to v2. |
My intention was to add this to the release announcement. Do you think the readme would be better? My main concern with GitHub is the way most projects are setup, people get to see the README of the unreleased next version, which is often confusing. |
IMO still worth, then if put in a Backward compatibility notes for pre-v0.x.x it would be easily skippable if it doesn't affect the reader. |
|
I don't understand. Could you make an example of how the mention would look in the README? |
|
(I'd love to have a checked-in release notes document, perhaps that would be so much cleaner, see #237) |
|
Added instructions for pre-v0.7.0 in the release notes document |
|
since #237 the release notes are searchable with github search (which doesn't search in the github releases text body) |
|
bors r+ |
235: Put support for v1 secret format behind feature flag r=mkmik a=mkmik In v0.7.0 (Mar 2018) we introduced per-item encrypted data and we deprecated the old "data" field that encrypted all the items in one blob. Since then every use of `kubeseal` would have produced sealed secret resources in such new format. Although it's unlikely that users have many such secrets around it would be unfriendly to just ditch this old format without giving a chance to users to notice whether they are having such secrets or not. Thus, the deprecation of this old format is gated via a feature flag. Since it's very unlikely people are going to be affected by this, the default value of the flag is set to break backward compatibility which means that only people who a) have sealed secrets resources that use the old flag, and b) cannot just reseal the secrets (with with `kubeseal --rotate`) would have flip the flag (and thus fiddle with the sealed-secrets controller env vars etc). Co-authored-by: Marko Mikulicic <mkm@bitnami.com>
Build succeeded |
|
uh I thought I had pushed the release notes to this PR but I forgot; I updated them independently |
In v0.7.0 (Mar 2018) we introduced per-item encrypted data and we deprecated the old "data" field that encrypted all the items in one blob.
Since then every use of
kubesealwould have produced sealed secret resources in such new format.Although it's unlikely that users have many such secrets around it would be unfriendly to just ditch this old format without giving a chance to users to notice whether they are having such secrets or not.
Thus, the deprecation of this old format is gated via a feature flag.
Since it's very unlikely people are going to be affected by this, the default value of the flag is set to break backward compatibility which means that only people who
a) have sealed secrets resources that use the old flag, and
b) cannot just reseal the secrets (with with
kubeseal --rotate)would have flip the flag (and thus fiddle with the sealed-secrets controller env vars etc).