On Monday, July 28, 2014 8:56:08 AM UTC-5, Dimitris Stafylarakis wrote: > > Hi people, > > thanks for your replies. My actual case is *run apt-get update before > upgrading a package*. So I have packages in my own repository and I'm > managing them through puppet on the production server. I want to be able to > set a specific version number and have puppet install the right version of > the package on the server. > > @pete: actually I am using puppetlabs/apt. It works fine when a new > package is being installed but for some reason doesn't trigger an update > when upgrading a package (i.e., changing the version number in the ensure > parameter). > > @john: I understand that it's difficult to determine a priori which > resources will be refreshed, I was just asking in case someone found a > smart solution to this already. For now, I have to resolve to running > updates on every puppet run. >
Let's be clear: there is no possible general solution -- smart or otherwise -- for determining which resources will be modified in advance of attempting to sync those resources. There are alternatives specific to some particular resource types and to some individual resources, but the general case requires unlimited ability to predict future events. Turning now specifically to Package resources in an Apt environment, let's think for a minute. What does 'apt-get update' do, and/or why do you need to run it before updating Packages? Well, it updates the local machine's cache of repository metadata, including especially the list of available packages, which Apt does not do unless asked. If you want to ensure that a given Package is at the latest version available from the repository, then you need the update process to draw on up-to-date repository metadata. No problem. But wait! How do you know whether there's an update to an installed package available at all? You need the current repository metadata for that, too. How do you ensure your copy of the metadata is up to date? Yes, 'apt-get update'. You cannot limit running 'apt-get update' to times when there is a Package update to apply, because you need to run it before you can determine whether there are any updates to apply at all. With that said, if it were ok for machines to lag a bit behind repository updates, then you could maybe apply a schedule <http://docs.puppetlabs.com/references/latest/type.html#schedule> to the 'apt-get update' Exec to limit when it can run or how many times it can run in a given period. That way it wouldn't need to run every time an agent applies its catalog, if that's what you're really after. That will reduce the average load on your Apt server for metadata requests, which are probably the bulk of the requests it services, but it will not reduce the load from serving actual packages. If you stagger nodes' metadata updates, however, then you will level out the load on your apt server from both kinds of requests. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3c9d2a8e-fa0d-452d-a6af-db0ba412598a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
