Flagger recreates existing services instead of updating the selector

[dhohengassner]

We are using flagger together with kapp.

Our Deployments and Services are managed with Kapp.
When I define a service that already exists it seems Flagger recreates it instead of just updating the selector (which would make sense to me).

Example:
In the Canary definition:

  service:
    # ClusterIP port number
    port: 80
    # container port number or name
    targetPort: http

kapp is detecting changes after the Canary updated the service:

@@ update service/techdocs (v1) namespace: techdocs @@
  0,  0   apiVersion: v1
  1,  1   kind: Service
  2,  2   metadata:
  3,  3     creationTimestamp: "2020-08-25T08:37:43Z"
  4,  4     labels:
  5     -     app: techdocs
      5 +     kapp.k14s.io/app: "1598340450001482819"
      6 +     kapp.k14s.io/association: v1.0a4bd06c2191404a8555ecb54e881e49
  6,  7     name: techdocs
  7,  8     namespace: techdocs
  8,  9     ownerReferences:
  9, 10     - apiVersion: flagger.app/v1beta1
 10, 11       blockOwnerDeletion: true
 11, 12       controller: true
 12, 13       kind: Canary
 13, 14       name: techdocs
 14, 15       uid: 8f8a88d4-c162-413f-8402-dc407015ae48
 15, 16     resourceVersion: "45529"
 16, 17     selfLink: /api/v1/namespaces/techdocs/services/techdocs
 17, 18     uid: acad321c-c6c3-4af6-b81b-59f6fda52c59
 18, 19   spec:
 19, 20     clusterIP: 10.100.167.230
 20, 21     ports:
 21, 22     - name: http
 22, 23       port: 80
 23     -     protocol: TCP
 24, 24       targetPort: http
 25, 25     selector:
 26     -     app: techdocs-primary
 27     -   sessionAffinity: None
     26 +     app: techdocs
     27 +     kapp.k14s.io/app: "1598340450001482819"
 28, 28     type: ClusterIP
 29, 29   status:
 30, 30     loadBalancer: {}
 31, 31

When I understand that correctly Flagger builds the resource new every time: https://github.com/weaveworks/flagger/blob/master/pkg/canary/service_controller.go#L80

Think it would help if Flagger at least would not touch user specified labels/annotations in metadata.

Any help or background is appreciated.
Thanks!

[stefanprodan]

You should remove the Kubernetes service from Git and let Flagger create it, this way the GitOps operator would ignore it.

[dhohengassner]

Thanks Stefan,

we did that but we have the same templates for multiple deployments where some of them use Flagger and some not.
It is possible to template that but we would prefer to manage the service using kapp.

We created this issue because it seems Flagger adjusts the service more than needed.

Is it possible to adjust Flagger here a bit to handle an update better?

[stefanprodan]

Think it would help if Flagger at least would not touch user specified labels/annotations in metadata.

The metadata can be set in the canary object, that's why Flagger overrides it every time. To improve this we could implement a 3-way-merge like kubectl does... I've been avoiding this as it complicated the code by a lot.

[dhohengassner]

Think the 3-way-merge is exactly what this issue is about :+1: