use of `puppet agent --enable` and `puppet agent --disable`

[neoice]

I'm investigating mcollective and it is aware of the Puppet3 --enable and --disable flags.

root@test3:~# puppet agent --disable "this is a test message"
root@test3:~# cat /var/lib/puppet/state/agent_disabled.lock  
{"disabled_message":"this is a test message"}#

using these flags allows mcollective to perform puppet runs on enabled hosts but not disabled hosts. in my current infrastructure using puppetctl, mcollective will run on puppetctl disabled hosts.

puppet agent --disable isn't as smart as puppetctl: there's no timed disables or motd modification.

if I wind up modifying puppetctl to support mcollective, are you interested in including the changeset in upstream? I think it might be as simple as also doing a puppet agent --{en,dis}able for the corresponding puppetctl actions.

[bhourigan]

Yeah, this would be very helpful. We have something similar on the short term roadmap and this would be a great help.

We were considering adding a function to puppetctl to allow a manual run while puppet is disabled (i.e. in noop), would this be possible after invoking puppet agent --disable?

[neoice]

doing a scrub of my open Github issues...

I've been running this in production for over a year now. I don't think I've had any problems.

are there any updates from Mozilla that you can publish? no new updates since Sep 2013!

[bhourigan]

Yeah of course. I'll push an update now. Although, we're still not using puppet's internal enable and disable toggle as we run puppet from cron.

[neoice]

I've been building a lot of automation with mcollective, but so far, I don't think I actually need the puppet mco agent at all. massive Puppet runs cause all kinds of bottlenecks (VM disk IO, HTTP request timeouts on Puppetmaster, HTTP requests/disk IO on rpm repos, etc).

I could probably remove the --enable/--disable stuff with no negative impacts. in fact, it annoys a few of my team mates because puppet agent --test --noop will refuse to run in disabled state!

[bhourigan]

I just merged an update for you.

Note that we changed the path to the disable state file, if you use that anywhere externally. It's OK to commit this change since any hosts that currently have puppet disabled will remain disabled. Only on their next puppet run will they pick up the path changes.

[neoice]

awesome. I currently have a lot of disabled hosts, so I might not push it out for a few weeks.

are you able to explain why the path was changed? just good housekeeping?

[bhourigan]

There is a comment inside puppetctl explaining the reason for the change. On RHEL /var/run is cleared at boot, so that had the unintentional side effect of re-enabling puppet. It wasn't a common use case, but it was a surprise for sure.