Dapr generates invalid service when target deployment uses select.matchExpressions instead of selector.matchLabels

[astromechza]

In what area(s)?

/area operator

/area docs

What version of Dapr?

1.1.x

Expected Behavior

When I submitted the following deployment, I expected the generated nodeapp-dapr service to use the match expressions.

apiVersion: apps/v1
kind: Deployment
metadata:
    name: node-example-app
spec:
    replicas: 1
    selector:
        matchExpressions:
            - key: score-workload
              operator: In
              values:
                - node-example-app
    template:
        metadata:
            annotations:
                dapr.io/app-id: nodeapp
                dapr.io/app-port: "3000"
                dapr.io/enable-api-logging: "true"
                dapr.io/enabled: "true"
            labels:
                score-workload: node-example-app
        spec:
            containers:
                - env:
                    - name: APP_PORT
                      value: "3000"
                    - name: STATE_STORE_NAME
                      value: redis-bhdai2
                  image: ghcr.io/dapr/samples/hello-k8s-node:latest
                  name: nodeapp

Actual Behavior

Due to

dapr/pkg/operator/handlers/dapr_handler.go

Line 289 in 58edd57

Selector: wrapper.GetMatchLabels(),

and

dapr/pkg/operator/handlers/wrappers.go

Line 20 in 58edd57

return d.Spec.Selector.MatchLabels

, the service ends up with NO selector, and ends up not matching any pods - making the service uncallable.

Steps to Reproduce the Problem

Follow the hello-world-kubernetes tutorial (with pythonapp and nodeapp) but replace the match labels in the node app with equivalent match expressions.

Release Note

RELEASE NOTE: FIX Dapr operator now correctly supports applications using matchExpressions.