Inconsistent labels created in pods

[jorgemoralespou]

I have two ways of deploying an image that should produce the same labels (described in the "How to reproduce section). I would expect that given that the labels in the DC and RC are the same, in the pods would also be the same, but they are quite different.

Version

Tested in minishift:

minishift v1.2.0

With oc client:

oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Server https://192.168.64.2:8443
openshift v1.5.1+7b451fc
kubernetes v1.5.2+43a9be4

Steps To Reproduce

To test this, it's required to use a cluster admin user.

oc adm new-project kube-dashboard

# Option 1
oc create deploymentconfig dashboard --image=gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.1 -n kube-dashboard
oc label dc/dashboard app=kube-dashboard -n kube-dashboard
oc set probe dc/dashboard --readiness --liveness --open-tcp=9090 --initial-delay-seconds=5 --timeout-seconds=1 -n kube-dashboard
oc expose dc/dashboard --port=9090 -l app=kube-dashboard -n kube-dashboard
oc expose svc/dashboard -l app=kube-dashboard -n kube-dashboard
oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:kube-dashboard:default
oc deploy dashboard -n kube-dashboard

# Option 2
oc new-app gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.0 --name=dashboard2 -n kube-dashboard

Current Result

 oc get all --show-labels --as=system:admin -n kube-dashboard
NAME            DOCKER REPO                                 TAGS      UPDATED         LABELS
is/dashboard2   172.30.1.1:5000/kube-dashboard/dashboard2   v1.6.0    7 minutes ago   app=dashboard2

NAME            REVISION   DESIRED   CURRENT   TRIGGERED BY                      LABELS
dc/dashboard    2          1         1         config                            app=kube-dashboard
dc/dashboard2   1          1         1         config,image(dashboard2:v1.6.0)   app=dashboard2

NAME              DESIRED   CURRENT   READY     AGE       LABELS
rc/dashboard-1    0         0         0         19m       openshift.io/deployment-config.name=dashboard
rc/dashboard-2    1         1         1         19m       app=kube-dashboard,openshift.io/deployment-config.name=dashboard
rc/dashboard2-1   1         1         1         7m        app=dashboard2,openshift.io/deployment-config.name=dashboard2

NAME                HOST/PORT                                       PATH      SERVICES     PORT       TERMINATION   WILDCARD   LABELS
routes/dashboard    dashboard.192.168.64.2.nip.io                             dashboard    9090                     None       app=kube-dashboard
routes/dashboard2   dashboard2-kube-dashboard.192.168.64.2.nip.io             dashboard2   9090-tcp                 None       app=dashboard2

NAME             CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE       LABELS
svc/dashboard    172.30.157.248   <none>        9090/TCP   19m       app=kube-dashboard
svc/dashboard2   172.30.163.251   <none>        9090/TCP   7m        app=dashboard2

NAME                    READY     STATUS    RESTARTS   AGE       LABELS
po/dashboard-2-46j86    1/1       Running   0          19m       deployment-config.name=dashboard,deployment=dashboard-2,deploymentconfig=dashboard
po/dashboard2-1-l9dnd   1/1       Running   0          7m        app=dashboard2,deployment=dashboard2-1,deploymentconfig=dashboard2

Expected Result

1. That pod created with first option will inherit label for app, app=kube-dashboard
2. That labels inherited for the pods in deploymentconfig both would have same values. As can be seen in the first pod (option 1) it has deployment-config.name and in second pod (option 2) it has deploymentconfig. In the RC they are correctly set.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[jorgemoralespou]

/lifecycle frozen