scheduling refresh event BEFORE dependent object
Dimitris Stafylarakis
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
Pete Brown
before a package install I can highly recommend the puppetlabs/apt
module on puppet forge I am using it in my environments and it does a
very good job at managing all of apt and friends.
https://forge.puppetlabs.com/puppetlabs/apt
If that really isn't the case and that was just an example the require
metaparameter is probably what you are looking for.
http://docs.puppetlabs.com/references/stable/metaparameter.html#require
> 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...@googlegroups.com.
> 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.
jcbollinger
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
Dimitris Stafylarakis
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
Christopher Wood
> 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.
apt-get clean
apt-get update
That said, I've tended to leave ensure=>present for packages and make sure that the versions I want are what I would get from "apt-get install packagename", rather than fight with specific deb versions and dependencies. (YMMV, obviously.)
> 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
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 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
Pete Brown
On 28 Jul 2014 23:56, "Dimitris Stafylarakis" <xan...@gmail.com> 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).
There is an option in the apt module to run apt-get update before every install but I am guessing you found that one.
There might be a setting for how often an update gets run.
Have you considered wrapping package in a define that does an update before the install and using that for your local package installs?
You could also setup a cron to do an apt-get update at regular intervals.
And now I think about it you could probably setup some kind of trigger in you local repo updated that trigger a mcollective to do the update.
>
> @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 puppet-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7991131-546e-4515-9ffb-2da1eb1e2605%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
jcbollinger
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 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
Dimitris Stafylarakis
I don't want the latest version of the package to be installed but a specific version that I configure through hiera. In that sense, there is indication of an upcoming package change that could somehow trigger an update.
This is all theory of course. Your (great) tip on using schedules is good enough for my case, as new versions of the package come out on a regular basis. So thanks a log for your help :)
cheers