puppet --no-client ignore USR1

[Fabrice Bacchella]

When puppet is launched as a daemon, a kill -USR trigger a catalog run :

Sep 21 12:56:01 XXX puppet-agent[15324]: Caught USR1; calling reload
Sep 21 12:56:24 XXX puppet-agent[15324]: Finished catalog run in 12.96 seconds

But when launched with --listen --no-client, nothing happens any more :

Sep 21 13:01:44 XXX puppet-agent[16858]: Caught USR1; calling reload
Sep 21 13:02:21 XXX puppet-agent[16858]: Caught USR1; calling reload

With only --listen, it still works.

I want to launch puppet in listen only mode, and schedule it using mcollective, but because a stack of different bugs, what should be a simple task is becoming a nightmare.

There is this one.

But there is also :
http://projects.puppetlabs.com/issues/4411
http://projects.puppetlabs.com/issues/8917

Can someone show me a way out of this maze ?

[jcbollinger]

On Friday, September 21, 2012 6:21:04 AM UTC-5, Fabrice Bacchella wrote:

When puppet is launched as a daemon, a kill -USR trigger a catalog run :

Sep 21 12:56:01 XXX puppet-agent[15324]: Caught USR1; calling reload
Sep 21 12:56:24 XXX puppet-agent[15324]: Finished catalog run in 12.96 seconds

But when launched with --listen --no-client, nothing happens any more :

Sep 21 13:01:44 XXX puppet-agent[16858]: Caught USR1; calling reload
Sep 21 13:02:21 XXX puppet-agent[16858]: Caught USR1; calling reload

With only --listen, it still works.

Yes, that's exactly what I would expect.  With --no-client, the agent only requests a catalog when it is signaled by the master.  The response to SIGUSR1 is a function of the client mode.
 

I want to launch puppet in listen only mode, and schedule it using mcollective, but because a stack of different bugs, what should be a simple task is becoming a nightmare.

There is this one.

But there is also :
http://projects.puppetlabs.com/issues/4411
http://projects.puppetlabs.com/issues/8917

Can someone show me a way out of this maze ?

I'm not very familiar with using MCollective to schedule Puppet runs, but bugs notwithstanding, it looks like you are asking for more from Puppet than you need to achieve that.

Have you considered not running the agent in daemon mode at all?  You should be able to use mco to perform "puppet agent --onetime --no-daemonize" at need.  If you don't *also* need the ability for the master to trigger Puppet runs over the listen interface, or for local processes to trigger runs via SIGUSR1, then that should completely cover your needs.

Even if you are running the agent with --listen --no-client (more on that in a moment), you can still trigger one-off agent runs of the puppet agent as described above.  That's safe inasmuch as Puppet uses a lock file to prevent overlapping runs.

You can work around the issue of agent options not recognized in the config file via Puppet's sysconfig interface (in some versions of Puppet, at least) or by modifying the actual service management script.  With the sysconfig interface, for example, you would install a file /etc/sysconfig/puppet, containing at least:

PUPPET_EXTRA_OPTS==--no-client

to make the service control script provide that option directly when it launches the agent.

If it essential that the agent accept SIGUSR1 to trigger a catalog cycle, then you must run in daemon mode with the client enabled (but --listen is not relevant to this question).  In that case you could consider setting the run interval to something very long, so that automated runs are very rare (except that runs will always happen at service startup).


John

[Fabrice Bacchella]

Le 21 sept. 2012 à 15:35, jcbollinger a écrit :

On Friday, September 21, 2012 6:21:04 AM UTC-5, Fabrice Bacchella wrote:

When puppet is launched as a daemon, a kill -USR trigger a catalog run :

Sep 21 12:56:01 XXX puppet-agent[15324]: Caught USR1; calling reload
Sep 21 12:56:24 XXX puppet-agent[15324]: Finished catalog run in 12.96 seconds

But when launched with --listen --no-client, nothing happens any more :

Sep 21 13:01:44 XXX puppet-agent[16858]: Caught USR1; calling reload
Sep 21 13:02:21 XXX puppet-agent[16858]: Caught USR1; calling reload

With only --listen, it still works.

Yes, that's exactly what I would expect.  With --no-client, the agent only requests a catalog when it is signaled by the master.  The response to SIGUSR1 is a function of the client mode.

But

in the manpage :

--no-client

Do not create a config client. This will cause the daemon to run without ever checking for its configuration automatically, and only makes sense when puppet agent is being run with listen = true in puppet.conf or was started with the --listenoption.

SIGUSR1

Immediately retrieve and apply configurations from the puppet master.

runinterval

How often puppet agent applies the client configuration; in seconds. Note that a runinterval of 0 means “run continuously” rather than “never run.” If you want puppet agent to never run, you should start it with the --no-client option.

• Default: 1800

How can I understand that you say from the documentation ? It says "checking for its configuration automatically", that's not the same thing as reacting to a signal.

Reacting to SIGUSR1 is the same kind of comportment as client : puppet waiting for external signals. The should go together.

 

I want to launch puppet in listen only mode, and schedule it using mcollective, but because a stack of different bugs, what should be a simple task is becoming a nightmare.

There is this one.

But there is also :
http://projects.puppetlabs.com/issues/4411
http://projects.puppetlabs.com/issues/8917

Can someone show me a way out of this maze ?

I'm not very familiar with using MCollective to schedule Puppet runs, but bugs notwithstanding, it looks like you are asking for more from Puppet than you need to achieve that.

Have you considered not running the agent in daemon mode at all?  You should be able to use mco to perform "puppet agent --onetime --no-daemonize" at need.  If you don't *also* need the ability for the master to trigger Puppet runs over the listen interface, or for local processes to trigger runs via SIGUSR1, then that should completely cover your needs.

When running using puppet through mco with onetime once, the run is synchrone : each catalog puppet must be finished before going to the next, it's too slow. When puppet is running as a daemon, the run is asynchrone and so much faster.

I was thinking about using the schedule type (http://docs.puppetlabs.com/references/latest/type.html#schedule), but I'm loosing hope. I don't expect it to run when runinterval is disabled, even if I think it should be.

Even if you are running the agent with --listen --no-client (more on that in a moment), you can still trigger one-off agent runs of the puppet agent as described above.  That's safe inasmuch as Puppet uses a lock file to prevent overlapping runs.

You can work around the issue of agent options not recognized in the config file via Puppet's sysconfig interface (in some versions of Puppet, at least) or by modifying the actual service management script.  With the sysconfig interface, for example, you would install a file /etc/sysconfig/puppet, containing at least:

PUPPET_EXTRA_OPTS==--no-client

to make the service control script provide that option directly when it launches the agent.

If it essential that the agent accept SIGUSR1 to trigger a catalog cycle, then you must run in daemon mode with the client enabled (but --listen is not relevant to this question).  In that case you could consider setting the run interval to something very long, so that automated runs are very rare (except that runs will always happen at service startup).

very rare and at service startup is not the same thing as never.

[jcbollinger]

I'm not well-versed in MCollective, but I would be surprised if it could not issue requests asynchronously.  Even if it can't natively do so, whatever node is issuing the mco commands certainly can issue several of them asynchronously.

 

I was thinking about using the schedule type (http://docs.puppetlabs.com/references/latest/type.html#schedule), but I'm loosing hope. I don't expect it to run when runinterval is disabled, even if I think it should be.

Puppet schedules are about what classes and resources are included in a catalog, not about whether the agent runs.

Either I don't understand what you're trying to achieve, or I don't understand why it achieving it is a problem for you. There are basically three ways the Puppet configuration client can run:

1. as a periodic function of the puppet agent daemon.  When, and only when, the agent is configured for this mode, you can additionally trigger an immediate configuration run at any time by having a local process issue Unix signal USR1 to the agent process.
2. as a remotely triggered function of the puppet agent daemon, via its listening interface.  This vector is almost completely independent of (1); the two can be distinguished by whether a local process or a remote one triggers configuration runs.
   
3. via a one-time local command with --onetime --no-daemonize (which itself may optionally be issued by an automated process, perhaps initiated remotely)
   

If you do not ever want the agent to initiate runs automatically, then either do not run it in daemon mode at all, or run it with --no-client --listen=true if you want to be able to trigger runs via the listening interface.  Either way, you can always initiate runs locally according to (3), provided only that there is not already a configuration run in progress.

So I agree with your initial premise that your task should be a simple one, and as far as I can tell that's what it is.  You can run automatically at fixed intervals (or not), you can trigger runs via network messages to the Puppet agent's built-in network service, or you can trigger runs at will manually or via whatever scheduling program you like (cron, mco, ...).  What else could Puppet reasonably offer that would make your task easier?  Or else, what functionality is Puppet missing that is needed for this to work?

John

[Fabrice Bacchella]

Le 24 sept. 2012 à 15:48, jcbollinger a écrit :

I'm not well-versed in MCollective, but I would be surprised if it could not issue requests asynchronously.  Even if it can't natively do so, whatever node is issuing the mco commands certainly can issue several of them asynchronously.

When the daemon is running, it does so by sending a SIGUSR1 to the daemon. If it's not, it run it and then wait for the end of the run. So when puppet run with --no-client, mco puppetd can't trigger catalog run.

Either I don't understand what you're trying to achieve, or I don't understand why it achieving it is a problem for you. There are basically three ways the Puppet configuration client can run:

1. as a periodic function of the puppet agent daemon.  When, and only when, the agent is configured for this mode, you can additionally trigger an immediate configuration run at any time by having a local process issue Unix signal USR1 to the agent process.

That's the point that really bother me because, it's not well explained in the manuals, and I don't agree with this choice. It should always react to this signal I think. Or perhaps what's is really missing is a way to have it lauched with --client, and no run interval, that's what 'run-interval=0' should do.

2. as a remotely triggered function of the puppet agent daemon, via its listening interface.  This vector is almost completely independent of (1); the two can be distinguished by whether a local process or a remote one triggers configuration runs.

I think that's the way I should go.

3. via a one-time local command with --onetime --no-daemonize (which itself may optionally be issued by an automated process, perhaps initiated remotely)
   

If you do not ever want the agent to initiate runs automatically, then either do not run it in daemon mode at all, or run it with --no-client --listen=true if you want to be able to trigger runs via the listening interface.  Either way, you can always initiate runs locally according to (3), provided only that there is not already a configuration run in progress.

So I agree with your initial premise that your task should be a simple one, and as far as I can tell that's what it is.  You can run automatically at fixed intervals (or not), you can trigger runs via network messages to the Puppet agent's built-in network service, or you can trigger runs at will manually or via whatever scheduling program you like (cron, mco, ...).  What else could Puppet reasonably offer that would make your task easier?  Or else, what functionality is Puppet missing that is needed for this to work?

I think that it's almost here, it's the communication with mco puppetd that should be improved.

[jcbollinger]

On Monday, September 24, 2012 6:25:53 PM UTC-5, Fabrice Bacchella wrote:

Le 24 sept. 2012 à 15:48, jcbollinger a écrit :

I'm not well-versed in MCollective, but I would be surprised if it could not issue requests asynchronously.  Even if it can't natively do so, whatever node is issuing the mco commands certainly can issue several of them asynchronously.

When the daemon is running, it does so by sending a SIGUSR1 to the daemon. If it's not, it run it and then wait for the end of the run. So when puppet run with --no-client, mco puppetd can't trigger catalog run.

That behavior must be a function of the particular MCollective 'agent' and/or 'client' you are using -- presumably ones provided by PuppetLabs.  If they're not doing what you want then it doesn't look like it would be hard to provide your own, especially inasmuch as you could borrow whatever you want from the PuppetLabs code.

Nevertheless, in my limited knowledge of MCollective I am surprised by your claim that it serializes control messages to nodes' puppet agents.  That seems contrary to the the system architecture, which is based -- as I understand it -- on broadcasting requests to all nodes in the target group, then collecting responses asynchronously.  Please forgive my ignorance here, but is that aspect of MCollective's behavior in fact what you should expect?
 

Either I don't understand what you're trying to achieve, or I don't understand why it achieving it is a problem for you. There are basically three ways the Puppet configuration client can run:

1. as a periodic function of the puppet agent daemon.  When, and only when, the agent is configured for this mode, you can additionally trigger an immediate configuration run at any time by having a local process issue Unix signal USR1 to the agent process.

That's the point that really bother me because, it's not well explained in the manuals, and I don't agree with this choice. It should always react to this signal I think. Or perhaps what's is really missing is a way to have it lauched with --client, and no run interval, that's what 'run-interval=0' should do.

Voting for the relevant tickets in PuppetLabs' bug tracker and adding your commentary there would be reasonable ways to attempt to stimulate changes.  Or buy a support contract and push for it via that channel.
 

2. as a remotely triggered function of the puppet agent daemon, via its listening interface.  This vector is almost completely independent of (1); the two can be distinguished by whether a local process or a remote one triggers configuration runs.

I think that's the way I should go.

3. via a one-time local command with --onetime --no-daemonize (which itself may optionally be issued by an automated process, perhaps initiated remotely)
   

If you do not ever want the agent to initiate runs automatically, then either do not run it in daemon mode at all, or run it with --no-client --listen=true if you want to be able to trigger runs via the listening interface.  Either way, you can always initiate runs locally according to (3), provided only that there is not already a configuration run in progress.

So I agree with your initial premise that your task should be a simple one, and as far as I can tell that's what it is.  You can run automatically at fixed intervals (or not), you can trigger runs via network messages to the Puppet agent's built-in network service, or you can trigger runs at will manually or via whatever scheduling program you like (cron, mco, ...).  What else could Puppet reasonably offer that would make your task easier?  Or else, what functionality is Puppet missing that is needed for this to work?

I think that it's almost here, it's the communication with mco puppetd that should be improved.

Yes, it sounds like it, though I'm still confused by how MCollective's behavior does not seem to be as advertised.

Good luck.


John