Watchers (2)

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

We've Moved!

I have recently started to use async_storeconfigs. My setup for this is I have puppetmaster, activemq and puppetqd all running on a system.

So what is happening is an agent performs a run. After the run the storeconfigs DB has the hosts.ip for the agent updated to the IP of the system that puppetqd is running on. If I turn async_storeconfigs off then the hosts.ip for the agent is updated to the correct IP of the agent itself.

I figured out that the incorrect IP being updated in hosts.ip from where puppetqd is running from because I took puppetqd off of the puppetmaster and ran it temporarily on another system to consume the queue from the puppetmaster. In this setup the IP changed from the IP of the puppetmaster (where puppetqd was previously running) to the new system running puppetqd.

History

Hey. Trying to work out what is going on here, I would appreciate a couple of bits more information from you:

Can you tell me the certname of one of the catalogs that is being improperly updated, and the certname of the machine that runs the Puppet queue daemon?

You can extract that with puppet agent --configprint certname

Can you also show puppet agent --configprint node_terminus on the queue machine only?

It looks like what is happening is that the queue daemon is getting node details that it thinks belong to the target node, but are really local, and is updating the request as a consequence. Those details will help track down the configuration causes of the problem.

Awesome, thanks. That helps form my theory, which is that we are merging the local facts, from Facter, into that request incorrectly, and then using that to extract the IP.

The problem seems to be the plain node terminus invokes node.fact_merge, which grabs facts from the configured fact terminus – in this case Facter. That terminus doesn’t actually check the node name on the request, and will return local facts for any query.

Unfortunately, the details of that node get consumed to set the IP, leading to this problem.

This seems to be related to Issue #3923 which was rejected from no one reproducing. That was set to High, should this one be set to High as well? I’d really love to use async_storeconfigs but this really kind of stops us from doing so. Thanks!

I would like to see this fixed soon as well. Our environment has forced us to go to async configuration and having the data in hosts table incorrectly, especially the “environment” column causes us pain.