James,

I vaguely remember seeing this 'node_terminus called twice' thing in the
past. The simple answer, though I know it's not what people want to
hear, is that the ENC should always return the right information. If you
want to modify the content of the catalog based on something that
happens between runs (which, by the way, I would highly suggest against,
and suggest that if you're doing that, something in your puppet
configuration is amiss), you should be checking somewhere like PuppetDB,
not changing it based on how many times the ENC script is run. Aside
from the problem you're having now, what happens if there's a timeout,
or some other failure after the ENC script is called but before the
catalog is applied?

-Jason

On 01/14/2014 06:20 PM, James Ellis wrote:
> Hi, chanced across this discussion when I noticed an ENC was being
> called twice. I understand I may not be using the ENC terminus exactly
> as it's been designed, but it's unexpected that it was called twice.
> Also worth noting that I can't see a note about the ENC being called
> twice here: http://docs.puppetlabs.com/guides/external_nodes.html
>
> In my case, I'm using an ENC to push virtual host changes to an agent
> running a web server, the YAML returned by the ENC uses
> create_resources to dynamically add resources to the catalogue.
> I observed via logging in the ENC script that on the first run, the
> ENC was excecuted but the catalogue was not applied, on the second run
> the catalogue was applied on the agent.
> This causes problems where we use an API to dynamically apply
> resources to a catalogue (1st run gets the catalogue resources,
> returns 'OK' to the API, 2nd run then tries to get resources but gets
> nothing as the 'OK'  sent to the API has effectively modified the
> resources to be applied).
>
> I've worked around this, for now, by using a lock file, so that the
> 'OK' API call is only run once but this still applies two calls to the
> API to dynamically get resources for the catalogue, where only one is
> required. I double checked the master and the agent configs, and the
> master only shows the ENC being referenced once and there is one
>  agent being run, only.
>
> Based on this, is there any way the agent can be set to call the ENC
> once only ? The only argument to the script is the agent hostname and
> there is no apparent difference in the environment of the first and
> second ENC calls.
>
> Using 3.4 O/S on ubuntu with the following agent command (run as root
> manually to debug) :
> puppet agent --no-usecacheonfailure --onetime --no-daemonize --server
> valid.server --verbose
>
>
> Thanks
> James
>
>
> On Monday, 23 September 2013 23:59:45 UTC+10, jcbollinger wrote:
>
>
>
>     On Friday, September 20, 2013 12:05:17 PM UTC-5, Greg Sutcliffe
>     wrote:
>
>         Is this puppet3? As I recall, in puppet3, the master makes a
>         separate call to the enc to determine the environment the
>         should authoritatively be in. Once that's established, it
>         makes a second call to get the classes and parameters.
>
>
>     Not exactly, but that may well be the right track.  It would be
>     pointless for the master to run the ENC more than once for catalog
>     compilation, for it would have no reason to expect that the ENC's
>     output would change.  HOWEVER, the master's file server may need
>     to run the ENC again to determine the environment from which to
>     serve 'source'd files.
>
>
>     John
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/373455ff-43f4-4f27-8667-ab896c240ea6%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52D5E717.1060604%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to