search

bookingcom / shipper

Kubernetes native multi-cluster canary or blue-green rollouts using Helm
Apache License 2.0
734 stars 38 forks source link

Add `metadata` to the `template` section for Applications #342

Open kanatohodets opened 4 years ago

kanatohodets commented 4 years ago

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.