Bug 1310052

Can you provide a json dump of the deployment config that was created by new-app?

# oc get dc node -o yaml 
apiVersion: v1
kind: DeploymentConfig
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  creationTimestamp: 2016-02-22T07:46:50Z
  labels:
    app: node
  name: node
  namespace: wjiang
  resourceVersion: "13855"
  selfLink: /oapi/v1/namespaces/wjiang/deploymentconfigs/node
  uid: 6ef5d9ee-d938-11e5-9cf1-fa163e544e12
spec:
  replicas: 1
  selector:
    app: node
    deploymentconfig: node
  strategy:
    resources: {}
    rollingParams:
      intervalSeconds: 1
      maxSurge: 25%
      maxUnavailable: 25%
      timeoutSeconds: 600
      updatePeriodSeconds: 1
    type: Rolling
  template:
    metadata:
      annotations:
        openshift.io/generated-by: OpenShiftNewApp
      creationTimestamp: null
      labels:
        app: node
        deploymentconfig: node
    spec:
      containers:
      - image: wjiang/node:latest
        imagePullPolicy: Always
        name: node
        resources: {}
        terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
  triggers:
  - type: ConfigChange
status:
  details:
    causes:
    - type: ConfigChange
  latestVersion: 1

The deployer pods use the 'default/deployer' service account for execution, not 'default:default'. Try adding your secret to the 'default/deployer' SA and see if the secret is automatically mounted.

(In reply to Dan Mace from comment #3)
> The deployer pods use the 'default/deployer' service account for execution,
> not 'default:default'. Try adding your secret to the 'default/deployer' SA
> and see if the secret is automatically mounted.

I do not think so. 
1. I have tried on devenv-rhel7_3509 with the same step, can not reproduce this.
2. Normal user have no permission to do things on default namespace, and the private image pulling is designed for normal user.

Guessing if this bug block this.
https://bugzilla.redhat.com/show_bug.cgi?id=1309195

If the container image you specify in a pod spec needs a secret to pull, you must specify the secrets in pod.spec.imagePullSecrets. This is as designed.

Maybe you're asking for the automatic addition of any SecretTypeDockercfg or SecretTypeDockerConfigJson secrets to the pod spec when generating a deploymentConfig via new-app? That sounds like a feature request for new-app. The deployment system shouldn't be responsible for automatically adding pull secrets to your deploymentConfig.


In the meantime you could simply edit the deploymentConfig to add the imagePullSecrets to the pod spec.

It seems like there are two potential RFEs out of this:

1) if the pod service account has a Dockercfg or DockerConfigJson secret, it should be added as an imagePullSecret to the pod as part of admission (how are multiple secrets handled?)

2) new-app could take a --pull-secret argument which it would use to properly add a pullSecret to the generated DeploymentConfig podtemplate

I've created https://trello.com/c/iatchS02/861-argument-to-set-secrets-in-new-app for (2).

Dan Mace, handing back to you for what, if anything, you want to do about (1).

Once you create a trello card (or reject the idea) I think this can be closed as upstream.

Can be reproduced on the dev-preview-int now.

Checked with
# openshift version 
openshift v3.2.0.17
kubernetes v1.2.0-36-g4a3f9c5
etcd 2.2.5

for both `oc secrets new hub .dockercfg=.docker/config.json --type=kubernetes.io/dockercfg` and `oc secrets new-dockercfg hub --docker-username=wjiang --docker-password=xxxxxx --docker-email=wjiang`

All can not work well.

And the pod.spec.imagePullSecrets contain the secrets.

# oc get pod node-3-cx0aa -o yaml 
<-------------snip----------->
spec:
<-------------snip----------->
  imagePullSecrets:
  - name: default-dockercfg-qpmo4
  - name: hub
<---------------snip--------------->

weiwei, Dan Mace, what would be the resolution? From the conversation it seems to me that from this point on, this is RFE. Not a bug.

Or is there something that needs to be fixed?

Checked with both latest ose 3.2 and dev-preview-int again, can reproduce this issue, should be a bug.

Could you please provide the exact reproduction steps, including any json/yaml for pods/deployment configs/etc? It would also be helpful if you could include the pull secret (feel free to sanitize the data, but I'm interested in seeing the keys). Also please make sure you run the node at log level 4, so we can see the node's logs with the info about pull secrets. Thanks!

Reproduce steps:
1. oc new-project wjiang
2. oc secrets new-dockercfg hub --docker-username=wjiang --docker-password=xxxxxx --docker-email=wjiang
3. oc secrets add sa/default secret/hub --for=pull
4. oc new-app wjiang/node:latest --name=node

And the node log(loglevel=5):
Apr 21 22:18:44 openshift-229.lab.sjc.redhat.com atomic-openshift-node[10999]: I0421 22:18:44.503608   10999 manager.go:1784] Got container changes for pod "node-1-rcrrf_wjiang(3be2b955-0830-11e6-9a36-fa163e0784e5)": {StartInfraContainer:false InfraChanged:false InfraContainerId:bf6c6c99c2558757c62684c1394bb32e6c7b7a0ca88dd1361f322212d4262b26 ContainersToStart:map[0:Container {Name:node Image:wjiang/node@sha256:78aa9f9f8e314449cfe79b4e4fdb820208ead3bca2d010d470a7ca7d1755b917 Command:[] Args:[] WorkingDir: Ports:[{Name: HostPort:0 ContainerPort:8080 Protocol:TCP HostIP:}] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:default-token-4sn2k ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount}] LivenessProbe:<nil> ReadinessProbe:<nil> Lifecycle:<nil> TerminationMessagePath:/dev/termination-log ImagePullPolicy:Always SecurityContext:0xc20a3527e0 Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.] ContainersToKeep:map[bf6c6c99c2558757c62684c1394bb32e6c7b7a0ca88dd1361f322212d4262b26:-1]}
Apr 21 22:18:44 openshift-229.lab.sjc.redhat.com atomic-openshift-node[10999]: I0421 22:18:44.503660   10999 manager.go:1921] Creating container &{Name:node Image:wjiang/node@sha256:78aa9f9f8e314449cfe79b4e4fdb820208ead3bca2d010d470a7ca7d1755b917 Command:[] Args:[] WorkingDir: Ports:[{Name: HostPort:0 ContainerPort:8080 Protocol:TCP HostIP:}] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:default-token-4sn2k ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount}] LivenessProbe:<nil> ReadinessProbe:<nil> Lifecycle:<nil> TerminationMessagePath:/dev/termination-log ImagePullPolicy:Always SecurityContext:0xc20a3527e0 Stdin:false StdinOnce:false TTY:false} in pod node-1-rcrrf_wjiang(3be2b955-0830-11e6-9a36-fa163e0784e5)
Apr 21 22:18:44 openshift-229.lab.sjc.redhat.com atomic-openshift-node[10999]: E0421 22:18:44.506409   10999 pod_workers.go:138] Error syncing pod 3be2b955-0830-11e6-9a36-fa163e0784e5, skipping: failed to "StartContainer" for "node" with ImagePullBackOff: "Back-off pulling image \"wjiang/node@sha256:78aa9f9f8e314449cfe79b4e4fdb820208ead3bca2d010d470a7ca7d1755b917\""
Apr 21 22:18:44 openshift-229.lab.sjc.redhat.com atomic-openshift-node[10999]: I0421 22:18:44.506507   10999 server.go:606] Event(api.ObjectReference{Kind:"Pod", Namespace:"wjiang", Name:"node-1-rcrrf", UID:"3be2b955-0830-11e6-9a36-fa163e0784e5", APIVersion:"v1", ResourceVersion:"81222", FieldPath:"spec.containers{node}"}): type: 'Normal' reason: 'BackOff' Back-off pulling image "wjiang/node@sha256:78aa9f9f8e314449cfe79b4e4fdb820208ead3bca2d010d470a7ca7d1755b917"
Apr 21 22:18:44 openshift-229.lab.sjc.redhat.com atomic-openshift-node[10999]: I0421 22:18:44.506577   10999 server.go:606] Event(api.ObjectReference{Kind:"Pod", Namespace:"wjiang", Name:"node-1-rcrrf", UID:"3be2b955-0830-11e6-9a36-fa163e0784e5", APIVersion:"v1", ResourceVersion:"81222", FieldPath:""}): type: 'Warning' reason: 'FailedSync' Error syncing pod, skipping: failed to "StartContainer" for "node" with ImagePullBackOff: "Back-off pulling image \"wjiang/node@sha256:78aa9f9f8e314449cfe79b4e4fdb820208ead3bca2d010d470a7ca7d1755b917\""



And can reproduce this with the same steps on dev-preview-int, but can not reproduce this on devenv-rhel7_4008.

I think there's some confusion because this bug was established as being an RFE and never got re-componentized to prevent further testing pending the resolution of the new Trello cards[1]. Pull secrets aren't automatically assigned to the DC created by new-app. Is this still the same case as originally reported? Please provide the deploymentConfig YAML that results from the `new-app` command. The steps provided don't work for me in dev-preview-int[2].

My current impression is that we shouldn't be testing this behavior at the moment. I'm changing the component to RFE.

[1]https://bugzilla.redhat.com/show_bug.cgi?id=1310052#c7
[2] (error: only a partial match was found for "wjiang/node:latest": "openshift/node:latest").

We are not considering adding the ability to specify push/pull secrets as part of new-app invocation right now, it's not a common use case.