----- Original Message ----- > On Apr 24, 2011, at 8:27 PM, R.I.Pienaar wrote: > > > > > On 24 Apr 2011, at 17:24, Luke Kanies <[email protected]> wrote: > > > >> On Apr 22, 2011, at 11:44 AM, Daniel Pittman wrote: > >> > >>> On Fri, Apr 22, 2011 at 10:18, Arm Adam > >>> <[email protected]> wrote: > >>> > >>>> Does puppet have any concept of a job engine with a request ID > >>>> so that > >>>> I can submit a request for a kick to happen, be given a request > >>>> ID, > >>>> and then be able to check back in for results for that specific > >>>> request ID? Or is the only way of knowing when it is done to > >>>> run kick > >>>> in --foreground mode? > >>> > >>> No. Specifically, Puppet doesn't even come close to having a > >>> model of > >>> that for the network. What we do have is MCollective, which is > >>> much > >>> closer. I don't recall if it does asynchronous operations yet, > >>> but it > >>> certainly allows the sort of remote control and verification on > >>> puppet > >>> runs that you are after. > >> > >> As Daniel says, mcollective is the only real way to do this kind > >> of work right now, but it is still essentially syncronous in > >> terms of control - you can't set up jobs and manage them > >> discreetly, as far as I know. > >> > >> However, I've been thinking a lot about this recently, and I > >> expect we'll be looking at whether it's reasonable to add > >> something like it to the system at some point, so I'd love to > >> hear about anything you come up with. > >> > > > > > > This kind of use is spec'd on the mcollectiv road map and there is > > some work going on at the moment to make this a good fit - mixing > > real time vs scheduled jobs. > > That's good to hear. I'm also interested in what amounts to > background jobs - something you start immediately, but isn't run > with a console attached. I don't know if this is any different in > infrastructure from scheduled jobs, though.
It can do this already - today they run immediately in future you can schedule them to run at 4am or whatever: % mco rpc --nr package yum_clean Request sent with id: 405d5413f423ed1b370539ac8ef9c7c2 and if we used time to measure how long this took from the user point of view: mco rpc --nr package yum_clean 0.30s user 0.03s system 91% cpu 0.357 total So all the machines are clearing their caches, I dont particularly care for the success or fail of this so dont want the interactive feedback and dont want to waste my time waiting for useless feedback. I use this for example to clear my yum caches whenever I add a package to the yum repo The eventual plan is that should you later start caring for the output you can ask it the result of a given job - 405d5413f423ed1b370539ac8ef9c7c2 in this case - and you can gain access to RPC results same as you do now > > > There is a prototype using puppet dsl as a way to express jobs and > > relations between them with failure resolution etc but this will > > work better further down the line > > > > I plan to work on this during the 1.3 x development series that > > should kick off soon, if you look in the mcollective issues list > > and roadmap on docs.puppetlabs.com you will see some more details > > on the current plans > > > > I am actively seeking feedback and requirements though to help plan > > this work as surprisingly it is not a feature that has actually > > been requested much so the picture of what people need isn't > > extremely clear. > > I know as we look at adding support in our web tools for phased > roll-out, we'll need this ability, but we haven't had enough time to > actually spec it out yet. Yup, I'd like mcollective to be an appropriate transport for BPM systems so will need that and a lot more. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
