[Puppet Users] scheduling refresh event BEFORE dependent object

On 25 July 2014 01:42, Dimitris Stafylarakis wrote:
Hi all,

I have a question for the experts in the group:

say there's an exec resource dependent on some other resource and
refreshonly=> true. As we know already, a change in the dependent resource
will send a refresh event to the exec resource. This will however be
scheduled for AFTER the change in the dependent resource (e.g. change a
configuration file for apache and then reload the service). I'd like to know
if it's possible to schedule the exec resource BEFORE the change (e.g. run
apt-get update before upgrading a package).

Any insights? Thanks in advance

Best regards,
Dimitris

--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/6e39d56f-234c-4e30-a645-b2c941020bc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Thursday, July 24, 2014 10:42:34 AM UTC-5, Dimitris Stafylarakis wrote:
Hi all,

I have a question for the experts in the group:

say there's an exec resource dependent on some other resource and
refreshonly=> true. As we know already, a change in the dependent resource
will send a refresh event to the exec resource. This will however be
scheduled for AFTER the change in the dependent resource (e.g. change a
configuration file for apache and then reload the service). I'd like to
know if it's possible to schedule the exec resource BEFORE the change (e.g.
run apt-get update before upgrading a package).

On Mon, Jul 28, 2014 at 06:56:08AM -0700, 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.

Thanks anyway

cheers,
Dimitris

On Friday, July 25, 2014 5:20:48 PM UTC+2, jcbollinger wrote:

On Thursday, July 24, 2014 10:42:34 AM UTC-5, Dimitris Stafylarakis
wrote:

Hi all,

I have a question for the experts in the group:

say there's an exec resource dependent on some other resource and
refreshonly=> true. As we know already, a change in the dependent
resource will send a refresh event to the exec resource. This will
however be scheduled for AFTER the change in the dependent resource
(e.g. change a configuration file for apache and then reload the
service). I'd like to know if it's possible to schedule the exec
resource BEFORE the change (e.g. run apt-get update before upgrading a
package).

No, it's not logically consistent.  If you want a resource A to be
refreshed in the event that a different resource, B, is changed, then
Puppet needs to sync B before it knows whether to refresh A.

Under some circumstances you can use Exec's 'onlyif' and/or 'unless'
parameter instead of 'refreshonly' and events.  Alternatively, you may
be able to use custom facts to help predict whether a specific resource
will be updated.  Details may depend on exactly what you're trying to
do.

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 [1][email protected].
To view this discussion on the web visit
[2]https://groups.google.com/d/msgid/puppet-users/c7991131-546e-4515-9ffb-2da1eb1e2605%40googlegroups.com.
For more options, visit [3]https://groups.google.com/d/optout.

References

Visible links
1. mailto:puppet-users+[email protected]
2. https://groups.google.com/d/msgid/puppet-users/c7991131-546e-4515-9ffb-2da1eb1e2605%40googlegroups.com?utm_medium=email&utm_source=footer
3. https://groups.google.com/d/optout

On 28 Jul 2014 23:56, "Dimitris Stafylarakis" wrote:
Hi people,

thanks for your replies. My actual case is run apt-get update before

--
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 [email protected].
To view this discussion on the web visit

For more options, visit https://groups.google.com/d/optout.

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.

On Tuesday, July 29, 2014 5:18:22 PM UTC+2, jcbollinger wrote:



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