Bug 1304935 - Heat logs gigabytes of boring, worthless stuff
Heat logs gigabytes of boring, worthless stuff
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity medium
: z4
: 7.0 (Kilo)
Assigned To: Zane Bitter
Amit Ugol
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-04 20:51 EST by Zane Bitter
Modified: 2016-04-26 16:04 EDT (History)
7 users (show)

See Also:
Fixed In Version: openstack-heat-2015.1.2-9.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, every time Heat loaded a stack - including just to get the metadata of a resource because os-collect-config is polling it - it logged at INFO level every single type mapping in the user's environment. For TripleO, in particular, there were many such mappings in the standard environment. A typical deployment of TripleO generated several Gigabytes of logs. This patch reduces the frequency of logging environment resources by logging all environment resources (e.g those from resource plugins and the global environment) only when starting the service, and logging user-provided template resources when validating template on create/update, for only the root stack, because this passes a derived subset environment down to all children. This update also switches to using the string representation of the ResourceInfo objects, as this contains more useful information than the previous log format.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-18 11:43:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1499330 None None None 2016-02-04 20:51 EST

  None (edit)
Description Zane Bitter 2016-02-04 20:51:03 EST
Every time Heat loads a stack - including just to get the metadata of a resource because os-collect-config is polling it - it logs at INFO level every single type mapping in the user's environment. Not one bug has ever been diagnosed as a result of this log message.

For TripleO, in particular, there are hundreds of such mappings in the standard environment. A typical deployment of TripleO generates *several Gigabytes* of logs. Checking the first heat-engine log file that came to hand from a TripleO undercloud, >96% of the messages logged were this of this one, useless type.
Comment 2 Amit Ugol 2016-02-16 05:53:05 EST
Just to make things clear, were you trying to avoid lines such as this?

2016-02-16 04:18:56.338 3643 INFO heat.engine.environment [req-06bdc530-48a0-4029-bf65-b610635c922a 4f751667f844476bbd039c89d824551d c8def687778d46c89936edaed7883144] overcloud Registered: [Template](User:True) OS::TripleO::AllNodes::SoftwareConfig -> file:///usr/share/openstack-tripleo-heat-templates/puppet/all-nodes-config.yaml


logs are still full of them (about 300 lines in a few hours), so what changed?

openstack-heat-engine-2015.1.2-9.el7ost.noarch
Comment 3 Zane Bitter 2016-02-16 10:45:06 EST
We should be logging them now when we create or update a stack (this includes nested stacks), so there could still be a bunch. What we don't do any more is log them any time we request data about a stack from the API - which happens not only when the user/client requests/polls data from Heat, but also when deployed servers request their metadata, which they each poll every 30s to see if they need to run any software deployments.
Comment 4 Amit Ugol 2016-02-16 23:00:03 EST
Seems reasonable.
Comment 6 errata-xmlrpc 2016-02-18 11:43:35 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-0266.html

Note You need to log in before you can comment on or make changes to this bug.