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.
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
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.
Seems reasonable.
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