Deployment labels and annotations are not duplicated

[lecourtoisn]

When applying a canary manifest the deployment clone named -primary is missing the fields labels and annotation from the original one.

Reading the documentation about labels and annotations, one might argue that labels are meant to be identifying and thus not-copied in the new deployment (although in my case I would like them duplicated or at least altered but present) but I can't think of a reason for ignoring annotations.

[stefanprodan]

Labels were removed due to jenkins-x/jx#3920

Flagger does copy the pods labels and annotations but not the deployment one, what's your use case for annotations?

[lecourtoisn]

We have an OPA rule that prevents us from making a deployment without a specific label. But I believe we don't need that rule anymore so we will remove it.

[worldtiki]

Sorry to dig this up but I ran into an issue with this.
I'm using kubemonkey which uses labels at the deployment level.

I wonder if we could revisit this and to use a whitelist of labels instead of not copying any?

[vishalwithme]

We also have this issue. We read deployment labels to pull some configurations. When -primary resources are created, Flagger doesn't move over old labels and hence we get into issues. There is a workaround though, we can have a 2 step approach. 1 creating canary with same version 2nd creating canary with new version. This solves the problem but looks like a hack than recommended solution.

[wolfmah]

Same issue here, problems with not having the labels set on deployments.

In our metrics dashboard, we want to parse data from ReplicaSet based on labels, but because the labels are not set on the Deployment object, we don't see any of our Canary deployments. We have to hard-code the name of our Canary services in the dashboard to show them. Not very friendly on a scalability term.

A whitelist system would great.

[stefanprodan]

I think we can have a --exclude-label-prefix="fluxcd,jenkins" command arg that will prevent these GitOps operators from deleting the primary deployment.

[worldtiki]

Makes sense. I think I can take a stab at this.

[jean-sandberg]

#709 will allow you to copy Kubernetes labels, but what about annotations?

[worldtiki]

Hi @jean-sandberg, that's a good point. When I opened #709 it was to solve the labels problem caused by the gitops operators.
As far as I know there is no restriction in simply copying the annotations (without any filtering) so I think we can modify the deployment controller and daemonset controller and copy those.

[stefanprodan]

@worldtiki you could add the annotations to your PR. Thanks!

[worldtiki]

@worldtiki you could add the annotations to your PR. Thanks!

Yes, of course.