Bug 1322245
Summary: | Logging deployer created logging-support-template in default namespace instead of the one specified for logging | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Xia Zhao <xiazhao> |
Component: | Logging | Assignee: | Luke Meyer <lmeyer> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | chunchen <chunchen> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 3.1.0 | CC: | aos-bugs, ewolinet, lmeyer, wsun, xiazhao |
Target Milestone: | --- | Keywords: | Regression, TestBlocker |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-04-06 13:21:35 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: |
Comment 5
Xia Zhao
2016-03-31 03:55:41 UTC
Set severity to high since this blocked the OSE 3.2 logging testing. @lmeyer The reason why I gave "cluster-admin" role instead of "edit" to logging-deployer serviceaccount is https://bugzilla.redhat.com/show_bug.cgi?id=1321855, I get the error overcomed as in the last paragraph of comment #2: <----quoted comment start----> After doing "oadm policy add-role-to-user cluster-admin system:serviceaccount:logging:logging-deployer" on master machine, the logging deployer can complete successfully. <----quoted comment end----> Please let me know if this work around is not appropriate to OSE, I should reopen the bug then. We should never be adding cluster-admin to any service account; it's a security hazard. Sorry that suggestion was made. https://bugzilla.redhat.com/show_bug.cgi?id=1321855 looks to me like much the same issue as here so I'd prefer to focus on this one. I reproduced the problem using your test environment and some different projects. The problem is that the latest 3.1 image deletes the kubeconfig it creates before running the oc commands it's intended for. I'm not sure where it's getting its kubeconfig from but perhaps it's smart enough to use the service account secret. In any case, after its kubeconfig is destroyed it defaults to the "default" project. I'll work on the fix. Should be fixed with 3.1.1-12 (I tested and it ran fine) Verified with deployer image 3.1.1-12, this issue has been fixed well. Thanks for your effort here, Luke. Closing this bug as it was fixed before release. |