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
{{ message }}
This repository has been archived by the owner on May 3, 2022. It is now read-only.
Shipper currently passes labels found on the Application object down to all of the Chart objects it creates.
This is a little surprising, and also violates the Kubernetes idiom of using a label or annotation change to do a "no-op" pod refresh - changing the Application labels does not trigger a new rollout, and the changes are only applied when objects are next created (next rollout). Additionally, only labels are mirrored, not annotations - per #44.
It would be a better, more Kubernetes centric design, to add a metadata field to the template. This metadata field should support labels and annotations. Any values should be injected into the Release, as well as the appropriate location of the objects installed by the Chart.
This would do a few things:
Reduce surprise (the label inheritance is not an obvious behavior), as we've discovered internally.
Enable "no-op" rollouts, by allowing users to change a label or annotation which is part of the template.
Facilitate stamping Releases with a range of build/test/release pipeline metadata, such as the human who kicked off the release, the build ID, etc. This would simplify development of tools which want to show all of the resources associated with a specific build: rather than needing to query Shipper to discover the Release name and fetch objects with that, they could fetch objects using an ID that they already know.
I think this approach would create straightforward semantics for #44, and provide a straightforward way to resolve #89.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Shipper currently passes labels found on the Application object down to all of the Chart objects it creates.
This is a little surprising, and also violates the Kubernetes idiom of using a label or annotation change to do a "no-op" pod refresh - changing the Application labels does not trigger a new rollout, and the changes are only applied when objects are next created (next rollout). Additionally, only labels are mirrored, not annotations - per #44.
It would be a better, more Kubernetes centric design, to add a
metadata
field to thetemplate
. Thismetadata
field should supportlabels
andannotations
. Any values should be injected into the Release, as well as the appropriate location of the objects installed by the Chart.This would do a few things:
I think this approach would create straightforward semantics for #44, and provide a straightforward way to resolve #89.
The text was updated successfully, but these errors were encountered: