Bug 1278180
| Summary: | The oc client inside a container does not automatically use the service account secret in the container | ||
|---|---|---|---|
| Product: | OKD | Reporter: | Cesar Wong <cewong> |
| Component: | oc | Assignee: | Clayton Coleman <ccoleman> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Wei Sun <wsun> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 3.x | CC: | aos-bugs, ccoleman, dmcphers, ffranz, jliggitt, mmccomas, xxia |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-23 21:17:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Cesar Wong
2015-11-04 20:59:24 UTC
Additional clarification for step 2 above: - Exec into the container with 'oc rsh [podname]', then try to use the 'oc' command Verification fails against version: openshift/oc v1.0.8-4-gabfc3c4 kubernetes v1.1.0-origin-1107-g4c8e6f4 Verification steps: 1. oc login, create project 2. create new app 1> $ oc new-app -f origin/examples/sample-app/application-template-stibuild.json 2> $ oc get pod NAME READY STATUS RESTARTS AGE database-1-rs0w0 1/1 Running 0 3h 3. Copy binary file "oc" to pod: 1> Create a directory in the pod container for "oc rsync" $ oc exec database-1-rs0w0 -- mkdir /tmp/xxia 2> Do the copy. (Binary file "oc" is under "localdir") $ oc rsync localdir/ database-1-rs0w0:/tmp/xxia 4. $ oc rsh database-1-rs0w0 bash-4.2$ /tmp/xxia/oc get pods Unable to connect to the server: dial tcp 172.30.0.1:443: i/o timeout Actual results: 4. Outputs error: Unable to connect to the server: dial tcp 172.30.0.1:443: i/o timeout Expected results: 4. The command works Additional info The above steps reproduce the bug if using old version oc such as v1.0.6. Are the above steps right to verify the bug? > The above steps reproduce the bug if using old version oc such as v1.0.6.
The bug was fixed in oc, so you need the latest version of oc. Are you saying it is only reproduceable in oc 1.0.6, or also in 1.0.8?
This is working for me on the latest master. A couple of things to remember: 1 - The service account that you are running the pod as must have permission to do the command that you invoke. This can be accomplished with a command like: $ oc policy add-role-to-user edit --serviceaccount=default 2 - Inside the pod, you must have the POD_NAMESPACE environment variable set to the current namespace. You can do this by either adding it to the deployment config or just set it before you invoke oc inside the pod: $ export POD_NAMESPACE=myproject $ oc get pods (In reply to Jordan Liggitt from comment #5) > > The above steps reproduce the bug if using old version oc such as v1.0.6. > > The bug was fixed in oc, so you need the latest version of oc. Are you > saying it is only reproduceable in oc 1.0.6, or also in 1.0.8? I mean that only 1.0.6 reproduces it. 1.0.8 does not reproduce it but has the issue as I described in the verification actual result. After testing according to your comment #6, that issue does not exist either. Verify again with the steps as in comment #4, and add the two points as in comment #6, the bug is fixed, the service account can run "oc get pods" successfully. Move it to VERIFIED. |