How to silence warning when ENC over-rides client's assumed environment?

asked 2014-11-24 02:18:25 -0500

me gravatar image

We're using an ENC to specify the environments that clients should be in, because we like this information being centralised. We are therefore not specifying an environment on the client (as far as we know).

This works great when the ENC puts the node into the default environment "production". However it doesn't work quite as well for nodes in other environments. What happens is:

  1. The client arbitrarily assumes that it's in the default environment "production". I understand that this is hard-coded into Puppet somewhere? Anyway, wherever it's getting this from, I don't believe it's anything we can control/defeat.
  2. The client then connects to the puppetmaster, whereupon it learns (from the ENC via puppetmaster) that it is actually in some other environment, not "production".
  3. The client then prints a large, bright red warning of the form: Warning: Local environment: "production" doesn't match server specified node environment "testing", switching agent to "testing".

The problems here as we see them are:

  1. This warning looks scary.
  2. Ignoring it for every puppet run on every non-production machine blunts our healthy sysadmin's reaction to bright red messages beginning with "Warning". Some day, we might miss a real problem as a result.
  3. We interpret this message as meaning that the client has made an arbitrary and incorrect assumption, then has later on learnt its error, but is for some reason complaining to us that it's made such assumptions. We think this is an instance of the good old "when you assume, you make an ass out of you and me".

Is there a way to silence this warning?

I can't find one, so I am seriously considering writing a wrapper script /usr/local/bin/puppet which grep -v's out this idiotic warning, then arranging to never again run the puppet executable directly. This will be very ugly; I fervently hope there's a better way.

I do not understand why there exists a default environment hard-coded into puppet (if that's true). I would have preferred that failure by the sysadmin to specify an environment on either client or server would be an error. But I suppose that changing that now would break existing puppet codebases.

edit retag flag offensive close merge delete