Bug #2834
external node classifier should take client's idea of the environment into account
| Status: | Closed | Start date: | 11/18/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | plumbing | |||
| Target version: | 3.0.0 | |||
| Affected Puppet version: | 0.25.4 | Branch: | ||
| Keywords: | environments | |||
| Votes: | 7 |
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
History
Updated by James Turnbull over 2 years ago
- Category set to plumbing
- Status changed from Unreviewed to Needs Decision
- Assignee set to Luke Kanies
Updated by Luke Kanies over 2 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.)
Updated by Daniel Beckham over 2 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?
Updated by Alan Barrett about 2 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
}
Updated by Alan Barrett about 2 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.)
Updated by Jesse Wolfe almost 2 years ago
- Target version changed from 2.6.0 to 52
Updated by James Turnbull about 1 year ago
- Target version deleted (
52)
Updated by Joshua Lifton 5 months ago
- Assignee deleted (
Jesse Wolfe)
This issue was assigned to a former Puppet Labs employee. Adding back to the pool of unreviewed issues.
Updated by Ben Hughes 4 months ago
- Description updated (diff)
- Status changed from Accepted to Unreviewed
Updated by Michael Stahnke 4 months ago
- Description updated (diff)
- Status changed from Unreviewed to Accepted
- Target version set to 3.X
- Keywords set to environments
Updated by Nigel Kersten 2 months 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.
Updated by Daniel Pittman 7 days ago
- Target version changed from 3.X to 3.0.0