Back to bug 1304854
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla Rules Engine | 2016-02-04 19:43:57 UTC | Target Release | --- | 7.0 |
| Zane Bitter | 2016-02-04 19:44:53 UTC | Status | ASSIGNED | POST |
| Zane Bitter | 2016-02-04 19:46:15 UTC | Blocks | 1304856 | |
| Zane Bitter | 2016-02-04 19:48:15 UTC | Link ID | OpenStack gerrit 272353 | |
| Zane Bitter | 2016-02-04 19:50:39 UTC | Target Milestone | --- | z4 |
| RHEL Program Management | 2016-02-04 19:55:06 UTC | Keywords | ZStream | |
| Zane Bitter | 2016-02-04 20:43:44 UTC | Status | POST | MODIFIED |
| Fixed In Version | openstack-heat-2015.1.2-8.el7ost | |||
| errata-xmlrpc | 2016-02-09 19:51:50 UTC | Status | MODIFIED | ON_QA |
| Lon Hohberger | 2016-02-09 19:53:26 UTC | Status | ON_QA | MODIFIED |
| errata-xmlrpc | 2016-02-09 21:24:44 UTC | Status | MODIFIED | ON_QA |
| Suyog Sainkar | 2016-02-16 05:08:52 UTC | CC | ssainkar | |
| Doc Text | Previously, when the metadata for a resource was requested from Heat, Heat fetched the value of every attribute of the resource, even though this data was not returned by the API. This meant at least one and possibly multiple pointless ReST API called to the OpenStack service underlying the resource. The metadata in Heat gets polled regularly by in-guest agents like os-collect-config, because it is the mechanism by which software deployments are triggered. In a large deployment (like a substantial TripleO cloud), there is a lot of polling, enough to put a substantial load on Heat. This was probably one of the reasons for the load. Additionally, because polling from a server generally uses a Heat "stack user" account from a different keystone domain rather than the stack owner's account, the resource cannot actually be found and the log is polluted with a lot of useless messages. The patch was updated to not calculate attributes for metadata request. This fix changes the default "with_attr" value in the RPC client to False, and only pass None (the previous default) or a list of extra attributes to include in the specific case where the ReST API will actually return the attribute values to the user and not just discard them which resolves the issue. This change also updates the ReST API unit tests to accurately reflect the data returned from the engine. |
|||
| Amit Ugol | 2016-02-16 12:17:36 UTC | Status | ON_QA | VERIFIED |
| Zane Bitter | 2016-02-16 15:59:42 UTC | Doc Text | Previously, when the metadata for a resource was requested from Heat, Heat fetched the value of every attribute of the resource, even though this data was not returned by the API. This meant at least one and possibly multiple pointless ReST API called to the OpenStack service underlying the resource. The metadata in Heat gets polled regularly by in-guest agents like os-collect-config, because it is the mechanism by which software deployments are triggered. In a large deployment (like a substantial TripleO cloud), there is a lot of polling, enough to put a substantial load on Heat. This was probably one of the reasons for the load. Additionally, because polling from a server generally uses a Heat "stack user" account from a different keystone domain rather than the stack owner's account, the resource cannot actually be found and the log is polluted with a lot of useless messages. The patch was updated to not calculate attributes for metadata request. This fix changes the default "with_attr" value in the RPC client to False, and only pass None (the previous default) or a list of extra attributes to include in the specific case where the ReST API will actually return the attribute values to the user and not just discard them which resolves the issue. This change also updates the ReST API unit tests to accurately reflect the data returned from the engine. | Previously, when the metadata for a resource was requested from Heat, Heat fetched the value of every attribute of the resource, even though this data was not returned by the API. This meant at least one and possibly multiple pointless ReST API calls to the OpenStack service underlying the resource. The metadata in Heat gets polled regularly by in-guest agents like os-collect-config, because it is the mechanism by which software deployments are triggered. Because polling from a server generally uses a Heat "stack user" account from a different keystone domain rather than the stack owner's account, the resource cannot actually be found and "404 Not Found" messages were accumulating in the logs of both heat-engine and nova-api. Heat no longer calculates attribute values when only the metadata for a resource is requested. |
| errata-xmlrpc | 2016-02-18 15:49:04 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2016-02-18 16:43:29 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2016-02-18 11:43:29 UTC | |||
| Perry Myers | 2016-04-26 13:23:58 UTC | CC | pmyers | |
| Red Hat One Jira (issues.redhat.com) | 2022-07-09 08:14:10 UTC | Link ID | Red Hat Issue Tracker OSP-16733 |
Back to bug 1304854