Jira (PDB-949) Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation.

[Charlie Sharpsteen (JIRA)]

Title: Message Title

Charlie Sharpsteen commented on PDB-949   Re: Retrieving facts that have had 'trusted' facts injected into them causes a 400 "Attempt to assign to a reserved variable name: 'trusted' on node" failure during Puppet catalog compilation. Kenneth Barber and I had a chat this morning and concluded that there are at least two cases in play here: It appears that for some agent catalog requests, the master is choosing to disregard the fact data provided by the agent and is instead falling back to cached facts or historic facts provided by PuppetDB. This is a Puppet bug if we have an authenticated agent requesting a catalog, we should always use the data provided by that agent. Caches and PuppetDB shouldn't be overriding this part of the transaction. For usecases which intentionally compile catalogs using historic data, such as puppet master compile and Catalog Preview, there is an issue with the trusted data being merged into the facts dataset. The compiler requires a Node object as input which has facts and trusted as separate datasets they cannot be merged. The first case with agent checkins has to be addressed on the Puppet side PuppetDB has no involvement with the processes that are misbehaving. There are two options for addressing the second case: The application, puppet master --compile, can munge Node objects retrieved from the indirector to ensure trusted data is removed from factsets and possibly re-added as trusted_data. This is currently the approach taken by Catalog Preview. The PuppetDB Node terminus can handle removing trusted data from factsets and possibly re-adding it as trusted_data. This would ensure the Node objects returned by the terminus store trusted data in the node.trusted_data attribute instead of having it mixed into the node.parameters attribute. I think the second option may be the best as it centralizes the handling of trusted data stored in PuppetDB and enables the node terminus to produce objects that can be passed directly to the compiler without further munging. The remaining question is whether we should re-add historical trusted data as 'trusted' or alter it in some way to indicate that the content is not tied to a current node request. Add Comment   This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.