Back to bug 1035199
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Steven Hardy | 2013-11-27 09:39:19 UTC | Priority | unspecified | medium |
| Status | NEW | ASSIGNED | ||
| Target Release | --- | 4.0 | ||
| Assignee | rhos-maint | shardy | ||
| Severity | unspecified | medium | ||
| Steven Hardy | 2013-11-27 09:41:40 UTC | Link ID | Launchpad 1252248 | |
| Steven Dake | 2013-11-27 12:40:03 UTC | Keywords | OtherQA | |
| Priority | medium | high | ||
| Severity | medium | high | ||
| Steven Dake | 2013-11-27 12:42:26 UTC | Blocks | 1035277 | |
| Steven Dake | 2013-11-27 12:43:20 UTC | Blocks | 1035277 | |
| Depends On | 1035277 | |||
| Steven Dake | 2013-11-27 14:52:19 UTC | Keywords | Triaged | |
| Steven Dake | 2013-12-06 02:37:08 UTC | Status | ASSIGNED | MODIFIED |
| Fixed In Version | python-heatclient-0.2.6-1.el6ost | |||
| Steven Dake | 2013-12-06 06:39:14 UTC | Target Milestone | --- | rc |
| errata-xmlrpc | 2013-12-06 19:36:35 UTC | Status | MODIFIED | ON_QA |
| Bruce Reeler | 2013-12-09 07:29:24 UTC | CC | breeler | |
| Flags | needinfo?(shardy) | |||
| Steven Hardy | 2013-12-11 13:05:57 UTC | Doc Text | Cause: The python-heatclient shell interface did not handle users passing existing tokens (via --os-auth-token) correctly. Consequence: Users passing existing keystone tokens to the heat CLI tool were unable to get that token correctly reused and passed to the heat-api in the request header. Fix: python-heatclient has been updated with a number of fixes which mean --os-auth-token should now work correctly. Result: --os-auth-token now works, in both normal and standalone modes, e.g: heat --os-auth-url http://127.0.0.1:35357/v2.0/ --os-auth-token <a keystone token> --os-tenant-id <tenant ID> <command> heat --os-no-client-auth --heat-url http://127.0.0.1:8004/v1/<tenant ID> --os-auth-token <a token> <command> | |
| Flags | needinfo?(shardy) | |||
| Steven Dake | 2013-12-11 18:52:54 UTC | QA Contact | kwhitney | jpeeler |
| Jeff Peeler | 2013-12-11 20:28:02 UTC | Status | ON_QA | VERIFIED |
| Don Domingo | 2013-12-11 22:30:47 UTC | CC | ddomingo | |
| Doc Text | Cause: The python-heatclient shell interface did not handle users passing existing tokens (via --os-auth-token) correctly. Consequence: Users passing existing keystone tokens to the heat CLI tool were unable to get that token correctly reused and passed to the heat-api in the request header. Fix: python-heatclient has been updated with a number of fixes which mean --os-auth-token should now work correctly. Result: --os-auth-token now works, in both normal and standalone modes, e.g: heat --os-auth-url http://127.0.0.1:35357/v2.0/ --os-auth-token <a keystone token> --os-tenant-id <tenant ID> <command> heat --os-no-client-auth --heat-url http://127.0.0.1:8004/v1/<tenant ID> --os-auth-token <a token> <command> | A bug in the python-heatclient shell interface prevented users from passing existing tokens correctly. Specifically, the '--os-auth-token' parameter always required a username; however, a username should only be required if the specified token is not tenant-scoped. This, in turn, prevented users from correctly reusing and passing tokens to the openstack-heat-api service in the request header. This fix ensures that '--os-auth-token' only requires a username when a token is not tenant-scoped. |
||
| errata-xmlrpc | 2013-12-19 17:42:19 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2013-12-20 00:39:24 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2013-12-19 19:39:24 UTC |
Back to bug 1035199