-
Notifications
You must be signed in to change notification settings - Fork 788
Description
Describe the feature
Hi, I was wondering if the ability to set primary labels/annotations as per this comment was implemented, and if not, would you accept a PR to add it?
I see it’s possible to set labels/annotations on the primary Service kinds but I don’t see a way to do this on a primary Deployment.metatdata.labels/annotations or HorizontalPodAutoscaler.metatdata.labels/annotations
This is a problem because we have governance rules for Kube object metadata, and it doesn't seem possible currently to update labels/annotations on the primary deployment/hpa if they change after the first successful canary rollout. They are correctly copied during first time deployment, but they remain static for any subsequent rollout.
Proposed solution
I want flagger to allow annotations and labels override on the primary deployment and hpa. This would be a change to the Canary Spec in a form similar to how service overrides work today:
service:
primary:
annotations:
key1: value1
labels:
key1: value1
For example:
deployment:
primary:
annotations:
key1: value1
labels:
key1: value1
autoscaler:
primary:
annotations:
key1: value1
labels:
key1: value1
Then it would be the responsibility of the consumer to pass along the updated map of labels/annotations to the Canary.
Any alternatives you've considered?
It would be possible to update the Promote function from e.g.
| func (c *DeploymentController) Promote(cd *flaggerv1.Canary) error { |
include-label-prefix filter for labels. Currently this function only seems to copy the Pod Spec labels/annotations.
This is probably easiest from a consumer point of view since it doesn't require any changes.
Is there another way to solve this problem that isn't as good a solution?