Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

Add metadata to the template section for Applications #342

Open
kanatohodets opened this issue Aug 19, 2020 · 0 comments
Open

Add metadata to the template section for Applications #342

kanatohodets opened this issue Aug 19, 2020 · 0 comments

Comments

@kanatohodets
Copy link
Contributor

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:

  1. Reduce surprise (the label inheritance is not an obvious behavior), as we've discovered internally.
  2. Enable "no-op" rollouts, by allowing users to change a label or annotation which is part of the template.
  3. 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant