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: > 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. > 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. > > 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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
