On Mon, Sep 6, 2010 at 11:52 AM, Silviu Paragina <sil...@paragina.ro> wrote: > On 06.09.2010 21:03, Nigel Kersten wrote: >> >> On Mon, Sep 6, 2010 at 10:56 AM, Silviu Paragina<sil...@paragina.ro> >> wrote: >> >>> As it was said earlier if you have a ensure => latest you should >>> probably >>> have (also) a cron job for updates. >> >> I think it's much more difficult to manage multiple schedules, and to >> deal with inconsistencies when people manually run Puppet at times >> that aren't in sync with your cron job than it is for Puppet to simply >> ensure the appropriate commands are run before your packages are >> installed. >> > Could you be a little more specific, I'm not sure if we are referring to the > same cron job. I'm not sure if you are referring to a "apt-get update" or a > "puppet" cron job. I was referring to a apt-get update cron.
Yep. That's the one I was talking about. > > You are right of course. If the apt-get update cron fails (or it hasn't got > the chance to run), puppet will have no ideea that it failed, and will still > run the package resources, which in some scenarios might be catastrophic. > But on the other hand if it just works like that and you really really need > the resources, you might consider using it. Thinking about it an apt-get > update shouldn't have more than 3-4 small files per repository if the cache > is hit, and otherwise it should have at most 10 files around a few hundred > bytes (in case of incremental repositories, not sure if incremental is the > right technical word, but I hope you understand what I meant) so there isn't > much of a penalty there, more supporting your solution. I should of probably > noted this in my answer, but most of it was already discussed in the thread > already. > > Now my solution was proposed in the idea that under no circumstance apt-get > update should be run every run (and, yes, I didn't take into account that > the reason for that might be wrong). > > I feel that I should point out again, that the solution is hackish and as > such, if used, it should be used only in a single module, preferably in a > single manifest, detailing in comments all the reasons for doing things the > way it does. And most of all if somebody doesn't follow the convention it > all goes down the drain. :) So my solution should be avoided if possible, > but if it can not be avoided, it works with the notes above. I'm pretty sure we're in agreement here :) > > > > Silviu > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
