Feature #4836
puppetd --disable improvements
| Status: | Closed | Start date: | 09/23/2010 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: |  Chris Price |
% Done: | 0% |
|
| Category: | error reporting | |||
| Target version: | 3.0.0 | |||
| Affected Puppet version: | 0.25.5 | Branch: | https://github.com/puppetlabs/puppet/pull/216 | |
| Keywords: | enable disable | |||
| Votes: | 6 |
Description
Occasionally I disable regular puppetd runs on a system by doing:
# puppetd --disable
This works fine, except that it could be improved in two ways:
- If it has been manually disabled, then when a run is attempted, it should print something more useful than this:
notice: Run of Puppet configuration client already in progress; skipping
because well… that message isn’t really true, its not in progress, rather it is currently disabled.
- The something more useful that it could print could be either a default message “notice: Puppet administratively disabled on this system; skipping”, or a custom message that you can pass to the puppetd —disable, eg. “puppetd —disable micah is fixing stunnel template” would then print the following when a puppetd was running: “notice: Puppet is administratively disabled because micah is fixing stunnel template; skipping run”
Related issues
History
Updated by James Turnbull over 1 year ago
- Category changed from unknown to error reporting
- Status changed from Unreviewed to Accepted
- Target version set to 2.7.x
- Affected Puppet version set to 0.25.5
Updated by Jonathan Kinred over 1 year ago
I regularly see this confusing new users.
I’d like to see the time that Puppet was locked in the output.
Less important, but what might also be nice is to allow time-based locking, like “lock for X minutes” or “lock until
Updated by Andrew Forgue over 1 year ago
It’s also an issue if you have a large number of puppet installs. There’s no way to tell if puppet was interrupted or it’s disabled for a reason. When you have 15 admins and 1000 hosts it’s hard to tell if someone disabled it on purpose or it broke.
Updated by micah - over 1 year ago
Jonathan Kinred wrote:
I regularly see this confusing new users.
Yeah, the confusing part is the message, which makes you think that puppet is currently running, which it is most certainly not doing, and not ever going to do until you enable it again.
Updated by James Turnbull 7 months ago
- Keywords set to enabledisable
Updated by Brice Figureau 6 months ago
- Status changed from Accepted to In Topic Branch Pending Review
- Branch set to https://github.com/puppetlabs/puppet/pull/216
Fixed in pull request 216, at the same time as #3757.
Updated by Jacob Helwig 5 months ago
- Status changed from In Topic Branch Pending Review to Merged - Pending Release
- Target version changed from 2.7.x to 2.7.10
This has been merged into 2.7.x in commit:86a806f595f8b7bb280c8c445eef51dfd71bf39d
commit 7777d91da0e7e7dffeb27db272ea9c37f4b8e4d9
Author: Brice Figureau <brice-puppet@daysofwonder.com>
Date: Sun Nov 13 10:07:47 2011
(#3757) - Refactor enable/disable to its own module
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
commit 0ffe1acc9221aaf5fb0d47b04a8c0a72cdbe0ba1
Author: Brice Figureau <brice-puppet@daysofwonder.com>
Date: Thu Dec 22 13:22:43 2011
(#4836) - Agent --disable should allow to put a message
This way it is possible to let other users know why a puppet agent
has been disabled.
Usage:
puppet agent --disable "because working on backup"
When later on, the puppet agent run would abort with:
"Run of Puppet configuration client is administratively
disabled because working on backup; skipping"
It's also possible to not set a message, in which case a default
message is provided.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
Updated by Michael Stahnke 4 months ago
- Status changed from Merged - Pending Release to Closed
released in 2.7.10rc1
Updated by Chris Price 3 months ago
- Status changed from Closed to Re-opened
- Target version changed from 2.7.10 to 3.X
Updated by Chris Price 3 months ago
- Status changed from Re-opened to Needs Decision
- Assignee set to Matthaus Litteken
Need input as to whether we should be trying to target this at 2.7.12. My inclination is no.
Updated by Matthaus Litteken 3 months ago
- Status changed from Needs Decision to Accepted
As this will change what is written to the file, and affect behavior of applications using those files, this should wait for telly. I don’t see a status for “move changes into different branch”, but i think that’s about where this ticket is at.
Updated by Matthaus Litteken 3 months ago
- Assignee changed from Matthaus Litteken to Chris Price
Updated by Chris Price 3 months ago
- Status changed from Accepted to Closed
- Keywords changed from enabledisable to enable disable
I introduced some confusion when describing this ticket to Haus; I had some of the details of this ticket mixed up with ticket #11057.
There are 2 requests in this ticket:
- better error message when agent is administratively disabled,
- user-definable error message.
These were both addressed in pull request 216, which has now been reverted from 2.7.12 (see #12844).
However, the first of those two behaviors can be accomplished without changing the lockfile semantics, and when I discussed this with Haus he stated that he would like to see that go into 2.7.12.
The second of those two behaviors does require a change to the lockfile semantics, so it’ll be put on hold until 3.x.
In hopes of making this a bit less confusing, I’m going to close this ticket out and open two new ones targeted at different versions.
Updated by Chris Price 3 months ago
Updated by Daniel Pittman 12 days ago
- Target version changed from 3.X to 3.0.0