FAQ
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 puppet-users+unsubscribe@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.

Search Discussions

  • Pete Brown at Jul 25, 2014 at 4:50 am
    If you are actually managing apt and need to trigger an apt-update
    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
    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 puppet-users+unsubscribe@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.
    --
    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJ8DPF79GAigC1P5%2BcGnLtH8RUi5cXqviQpvck7KTBc%3DZk4YYw%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jcbollinger at Jul 25, 2014 at 3:20 pm

    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ed82b7e7-cf99-4680-93d6-7c73b253f10b%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Christopher Wood at Jul 28, 2014 at 3:03 pm

    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.
    In this situation I've tended to go for the least intelligent solution, doing this on every agent run:

    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.)
    @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]puppet-users+unsubscribe@googlegroups.com.
    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+unsubscribe@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
    --
    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140728150342.GA29208%40iniquitous.heresiarch.ca.
    For more options, visit https://groups.google.com/d/optout.
  • Pete Brown at Jul 29, 2014 at 2:29 am

    On 28 Jul 2014 23:56, "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).

    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+unsubscribe@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.
    --
    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJ8DPF6%3Di%2BrgP%2B4cy0i2XxsoqvXLWJdc-R7mTNb%3DD4TifRXb5w%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jcbollinger at Jul 29, 2014 at 3:18 pm

    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+unsubscribe@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.
  • Dimitris Stafylarakis at Aug 5, 2014 at 12:50 pm
    hi John,

    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
    On Tuesday, July 29, 2014 5:18:22 PM UTC+2, jcbollinger wrote:


    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+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e32d2b8c-faee-40d4-b779-28c8647a4785%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 24, '14 at 3:43p
activeAug 5, '14 at 12:50p
posts7
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase