The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #4479

run required exec ONLY when the thing requireing it is actually going to be executed.

Added by Klavs Klavsen about 4 years ago. Updated over 2 years ago.

Status:Needs More InformationStart date:08/05/2010
Priority:NormalDue date:
Assignee:Klavs Klavsen% Done:

0%

Category:metaparameters
Target version:-
Affected Puppet version: Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

I currently have:

Package {
  provider => "aptitude",
  require => [Exec["apt-update"]
}

But this runs the Exec on EVERY puppet run – even though puppet is not actually installing any package in a relevant run (because all packages are already installed in correct versions).

My thinking is that puppet should only run the exec if it is going to change the package state.

I realize that if the require was changed to only be evaluated if the package state needed changing, then one could remove a requirement after it was installed – and puppet wouldn’t fix it.

Perhaps an inverse notify (pre-run or something) instead of require could be added ?

History

#1 Updated by Markus Roberts about 4 years ago

  • Status changed from Unreviewed to Rejected

From your description the present behaviour sounds correct; if, for example, a package was set to ensure latest, there would be no way to tell if the installed version was the latest until after the script was run.

If you disagree, you may reopen the ticket but please explain your disagreement in detail.

#2 Updated by R.I. Pienaar about 4 years ago

  • Status changed from Rejected to Re-opened

I think this has merit,

The exec as shown in the code will run on every puppet run, even if we’re not going to change any packages. This puts unneeded load on apt servers etc and can be a big pain in a large site.

the feature the requester wants is this:

pckage{"foo":
   ensure => 1.2.3,
   update_cache => yes,
}

So on the puppet run when you validate the package and discover it is not 1.2.3 then you’ll run apt-get/yum make cache/whatever is appropriate for the provider at that point and at that point only and then make the resource be 1.2.3.

ensure => latest will more or less break the model since you have a chicken and egg situation, you dont know if its latest till you’ve updated the cache. But for version specific or ensure => present resources this would be a great thing.

#3 Updated by Klavs Klavsen about 4 years ago

Well – perhaps it should be a feature request then.

Puppet doesn’t know what the exec does – and without that exec I manually setup for the Package clause – it would never be able to ensure latest version was installed (as it doesn’t run apt-get update – even though it should know this was necessary).

IMHO since puppet knows if a package needs to be latest (and that this means it would require an apt-get update) – puppet should on it’s own accord – run apt-get update – in 3 circumstances: 1) if it has a package where it needs to ensure latest 2) if it has a package – where the requested version is NOT in the repo cache 3) if a package install fails – it may be that the cache is so old, so the files are no longer available.

#4 Updated by Alan Barrett about 4 years ago

Klavs Klavsen wrote:

puppet should on it’s own accord – run apt-get update – in 3 circumstances: 1) if it has a package where it needs to ensure latest 2) if it has a package – where the requested version is NOT in the repo cache 3) if a package install fails – it may be that the cache is so old, so the files are no longer available.

I like this idea. It should be generalised to allow both the package provider and the manifest to specify a command to run when one of the above three conditions applies.

#5 Updated by James Turnbull about 4 years ago

  • Tracker changed from Bug to Feature

#6 Updated by James Turnbull almost 3 years ago

  • Category set to metaparameters
  • Status changed from Re-opened to Needs Decision
  • Assignee set to Nigel Kersten

#7 Updated by Nigel Kersten over 2 years ago

  • Status changed from Needs Decision to Needs More Information
  • Assignee changed from Nigel Kersten to Klavs Klavsen

I’d like to see the people pushing for this feature describe how this would work.

  • Where is the info about “how to update the package cache” stored? In the providers? In a manifest?
  • Do users get to disable this?
  • When does it run?
  • How do users ensure that this happens after any new repositories are created but before any packages are updated?
  • What do we do about the people who are using packages to set up repositories?
  • Does this abstract cleanly across a majority of our package providers?

Assigning to Klavs as he made the suggestion :) but watching the ticket.

Also available in: Atom PDF