Issue #3537 has been updated by micah -.
eric sorenson wrote:
> micah :
>
> > What is it about #3 that is problematic?
>
> Because you need to `apt-get update` periodically for `ensure => latest` to
> work.
It is sufficient to do *one* apt-get update during a puppet run if any package
resource requires that it be done. If something changes in the repository
during a puppet run, we should not have to worry about that, the next run can
handle that.
> > It seems to me that if an apt-get update were to be done for any of those
> > three conditions, I would think that the apt-get update run would be
> > scheduled to run for that puppet run, not for each package that is
> > installed. In otherwords, it seems sufficient to me to have 5 different
> > package resources, satisfying any of those three conditions you outlined
> > above, each notifying an apt-get update resource that would then run one
> > time before doing those operations.
> OK, maximum 1 update per puppet run at the beginning of the run is exactly
> what Nigel's two lines in [note 6](#note-6) accomplish, which seems OK to me
> but other comments here said that was too frequent.
I think that one update per puppet run is fine, but only if it is necessary
based on the package resources. I'm not sure about it happening at the
beginning or not, because I would think that it would be better if it were only
done if it should be done, which would require inspection of the package
resources.
For clarity sake, lets describe an example. Lets pretend we have the following
package resources:
package { 'foo': ensure => '2.6.5-2' }
package { 'bar': ensure => latest }
package { 'baz': ensure => '1.2.2-6' }
Ok, now puppet runs, it has a look at the system and it finds that 'foo' is
installed and its version is '2.6.5-2', so it doesn't need to do anything for
that package resource. Move along, nothing to see here.
When it looks at 'bar' it sees that it needs to be the latest version, so it
schedules an apt-get update to make sure that it has the latest package state
before doing anything.
Then it looks at package 'baz', and it sees that the version installed on the
system is '1.1-1', so it says ok, I need to install a different package. Puppet
can do one of two things here: a) it tries to determine if 1.2.2-6 is possible
to install right now (this can be done by querying the package database) and if
so goes ahead with the install, and if not then it looks to see if an apt-get
update has been run, and if not schedules an apt-get update; b) or look to see
if an apt-get update has been run and if not schedule an apt-get update no
matter what, to make sure that we have the latest package state before doing
anything
So now that all package resources have been inspected, we have an apt-get
update event scheduled (perhaps twice depending on what is done with package
'baz') so then the apt-get update happens and then those package resources are
run again, this time being aware that an apt-get update has happened.
----------------------------------------
Feature #3537: It should be possible to trigger (exec) resources with require
https://projects.puppetlabs.com/issues/3537#change-93262
* Author: Kjetil Torgrim Homme
* Status: Needs Decision
* Priority: Normal
* Assignee: eric sorenson
* Category: metaparameters
* Target version:
* Affected Puppet version: 0.25.4
* Keywords:
* Branch:
----------------------------------------
When an Exec has conditions associated with it (unless, creates, onlyif), it
can be useful to be state prerequisites which are only run when the exec itself
is run.
Consider this simple example::
<pre>
exec { "prereq":
command => "/bin/echo prereq",
refreshonly => true
}
exec { "main":
command => "/bin/echo main",
onlyif => "/bin/grep foobar /etc/issue",
require => Exec["prereq"]
}
</pre>
Here, the refreshonly will cause "prereq" to never run, since a require isn't
enough to trigger it. Without refreshonly, it will run every time, but the
desired behaviour is that "prereq" is run iff the onlyif command succeeds.
Obviously the behaviour of "refreshonly => true" can't change, and I can't
think of a good name for a tri-state alternative -- "refreshonly =>
'requires-too'" ? "allevents" may be more workable.
My prefered solution would be a new parameter "requireonly". Perhaps slightly
misleading name, since "before" should trigger execution, too, but I think most
people will understand that require/before are inherently intertwined. This
could later be generalised into a metaparameter to work for more types, e.g.
you could have a parent File which is only checked/updated/created when some
other File requires it.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
