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. > > 1. 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. > > > 1. > 2. 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/0vXfhEKQ8P8J. 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.
