The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #2834

external node classifier should take client's idea of the environment into account

Added by Alan Barrett over 4 years ago. Updated almost 2 years ago.

Status:ClosedStart date:11/18/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:plumbing
Target version:3.0.0
Affected Puppet version:0.25.4 Branch:
Keywords:environments

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

This is a feature request. I would like the external node classifier to be the final authority over what environment is used for each client, but I would like the node classifier to have access to more than just the client hostname when making its decision. I would especially like the node classifier to have access to the environment value that the client requests, but it may also be useful to have access to more facts.

For example, I would like to be able to write an external node classifier that incorporates rules like this:

  • any node may request to be in the “bootstrap” environment at any time
  • certain nodes may switch back and forth between the “test” or “dev” environments whenever they like, but may never be in the “prod” environment
  • certain nodes are always in the “prod” environment (unless they request to be in the “bootstrap” environment)

Issue #2748 is related.


Related issues

Related to Puppet - Feature #2356: access to facts in external nodes Closed 06/22/2009
Related to Puppet - Bug #3910: Server is not authoritative over client environment when ... Closed
Duplicated by Puppet - Bug #2748: config file takes priority over external_nodes in 0.25.x Duplicate 10/22/2009

History

#1 Updated by James Turnbull over 4 years ago

  • Category set to plumbing
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies

#2 Updated by Luke Kanies over 4 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee changed from Luke Kanies to Jesse Wolfe
  • Target version set to 2.6.0

(Removed comment applied to wrong ticket.)

#3 Updated by Daniel Beckham about 4 years ago

One thing that this does not cover is the need/want to be able to specify an environment on the command line. Currrently, if you use something like:

puppetd --environment=foo --test --noop

Whatever is defined in the external node database will be used instead of what was passed on the command line. This makes it hard to do a noop check on a production node that you can’t or do not want to actually move to testing or development.

Can we somehow force the command line parameter to override all?

#4 Updated by Alan Barrett about 4 years ago

Daniel Beckham wrote:

Whatever is defined in the external node database will be used instead of what was passed on the command line. This makes it hard to do a noop check on a production node that you can’t or do not want to actually move to testing or development. Can we somehow force the command line parameter to override all?

The external node classifier is not just a database; it can contain arbitrary code. Under my proposal, I think you could satisfy your use case (which is also a use case that I have) using logic like this in the external node classifier:

if (client asked to be in the testing or development environment,
    and client would normally be in the production environment)
{
    allow client to be in the environment that it asked for
}
else
{
    ignore what client asked for
}

#5 Updated by Alan Barrett almost 4 years ago

  • Affected Puppet version changed from 0.25.1 to 0.25.4

Apparently the facts from the client are stored in $vardir/yaml/facts before the external node classifier is invoked. The node classifier could obtain the facts from there. (Thanks to Dan Bode for informing me of this.)

#6 Updated by Jesse Wolfe almost 4 years ago

  • Target version changed from 2.6.0 to 52

#7 Updated by James Turnbull about 3 years ago

  • Target version deleted (52)

#8 Updated by Joshua Lifton over 2 years ago

  • Assignee deleted (Jesse Wolfe)

This issue was assigned to a former Puppet Labs employee. Adding back to the pool of unreviewed issues.

#9 Updated by Ben Hughes about 2 years ago

  • Description updated (diff)
  • Status changed from Accepted to Unreviewed

#10 Updated by Michael Stahnke about 2 years ago

  • Description updated (diff)
  • Status changed from Unreviewed to Accepted
  • Target version set to 3.x
  • Keywords set to environments

#11 Updated by Nigel Kersten about 2 years ago

  • Status changed from Accepted to Closed

So we’re definitely fixing the issue where the ENC can’t set the environment reliably.

To work out what the client thinks the environment is, you can investigate the yaml cache on disk, or the inventory service via the APIs.

I’m going to close this, as I don’t believe we have anything special we have to implement here, but if that’s not the case, please reply.

#12 Updated by Daniel Pittman almost 2 years ago

  • Target version changed from 3.x to 3.0.0

Also available in: Atom PDF