FAQ
Hi all,

I'm a reasonably experienced puppet user but I'm running into a problem
with yumrepos where 'before' and 'require' don't seem to be behaving how I
expect.

class repos::atomic {
package { 'atomic-release':
ensure => installed,
source => '
http://www6.atomicorp.com/channels/source/atomic-release/atomic-release-1.0-15.el6.art.noarch.rpm',

before => Yumrepo['atomic'],
}

# After installing the repo, tweak it to limit it to ossec* packages
yumrepo { 'atomic':
name => 'atomic',
includepkgs => 'ossec-hids*',
require => Package['atomic-release'],
}
}

In theory, this chunk of code installs the atomic-release RPM package,
which sets up /etc/yum.repos.d/atomic.repo and handles the GPG key. Then,
my Yumrepo block runs and modifies atomic.repo to add the includepkgs
line.l

If the RPM is installed before the Yumrepo, then this works. However, quite
often it seems the Yumrepo block is run first, creating an atomic.repo file
with nothing other than the includepkgs line, and then the RPM is
installed, which notices that atomic.repo exists and creates
atomic.repo.rpmnew - leaving me with a broken yum configuration.

This occurs even with the before => Yumrepo['atomic'] and require = >
Package['atomic-release'] lines in place, which is not what I expect. Am I
missing a subtlety?

Cheers,
Jonathan

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/QxI8Unu9HEoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Matthew Burgess at Jan 24, 2013 at 3:18 pm

    On Thu, Jan 24, 2013 at 2:49 PM, wrote:

    This occurs even with the before => Yumrepo['atomic'] and require = >
    Package['atomic-release'] lines in place, which is not what I expect. Am I
    missing a subtlety?
    I'd be tempted to remove the 'before' parameter to the package;
    declare the dependency in just one place,i.e. the yumrepo. I'd also
    try adding "provider => 'rpm'" to the package, just to ensure it's not
    trying to find the RPM in one of your existing repos.

    The docs do say, for 'provider': "You will seldom need to specify this
    — Puppet will usually discover the appropriate provider for your
    platform." However, it doesn't say whether or not specifying the
    'source' parameter will override whatever provider it would normally
    choose for your platform.

    I'm not sure that either or both suggestions will fix your issue, but
    it otherwise looks like it should do the right thing.

    Thanks,

    Matt.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jonathan Gazeley at Jan 24, 2013 at 3:30 pm

    On 24/01/13 15:18, Matthew Burgess wrote:
    On Thu, Jan 24, 2013 at 2:49 PM, wrote:

    This occurs even with the before => Yumrepo['atomic'] and require = >
    Package['atomic-release'] lines in place, which is not what I expect. Am I
    missing a subtlety?
    I'd be tempted to remove the 'before' parameter to the package;
    declare the dependency in just one place,i.e. the yumrepo. I'd also
    try adding "provider => 'rpm'" to the package, just to ensure it's not
    trying to find the RPM in one of your existing repos.
    Thanks for your response. I initially tried it without the 'before', and
    only added the 'before' when I noticed that it wasn't worked as expected.

    I'll have a go at explicitly setting the RPM provider. Trouble is, it's
    quite hard to test this because it seems hit and miss whether new nodes
    mess up the order or not.

    The other solution might be to forget about the atomic-release.rpm and
    simply use the Yumrepo resource type to set up the whole repository, but
    then I need to reimplement half the stuff surrounding fetching and
    installing the GPG key. Doesn't seem like a great idea. How have other
    people dealt with this?

    Cheers,
    Jonathan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Matthew Burgess at Jan 24, 2013 at 3:57 pm

    On Thu, Jan 24, 2013 at 3:30 PM, Jonathan Gazeley wrote:
    On 24/01/13 15:18, Matthew Burgess wrote:
    On Thu, Jan 24, 2013 at 2:49 PM, wrote:

    This occurs even with the before => Yumrepo['atomic'] and require = >
    Package['atomic-release'] lines in place, which is not what I expect. Am
    I
    missing a subtlety?
    I'd be tempted to remove the 'before' parameter to the package;
    declare the dependency in just one place,i.e. the yumrepo. I'd also
    try adding "provider => 'rpm'" to the package, just to ensure it's not
    trying to find the RPM in one of your existing repos.
    Thanks for your response. I initially tried it without the 'before', and
    only added the 'before' when I noticed that it wasn't worked as expected.

    I'll have a go at explicitly setting the RPM provider. Trouble is, it's
    quite hard to test this because it seems hit and miss whether new nodes mess
    up the order or not.
    Yeah, that suggests the dependency chain hasn't been declared
    correctly; puppet, in the absence of dependency info, will apply
    manifests in any order it cares to. It might be worth turning on the
    dependency graphing support on your puppet master
    (http://docs.puppetlabs.com/references/3.0.latest/configuration.html#graph
    and graphdir directly below that). That is probably just going to
    confirm what you already suspect though, that there isn't a dependency
    between your yumrepo and the package, despite it looking like you've
    declared one.

    Thanks,

    Matt.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Ellison Marks at Jan 24, 2013 at 6:11 pm
    Just my two cents here. I've had some major problems in the past with using
    puppet to manage a file installed by a package which is also managed by
    puppet. Now, I haven't revisited the problem since 2.6, but my intuition
    was that since the file to be managed didn't exist at the start of the run,
    puppet got confused and flubbed the dependencies. My "solution" was to
    handle installing repos when I install the machine, as part of the
    kickstart.
    On Thursday, January 24, 2013 6:49:25 AM UTC-8, jg4...@bristol.ac.uk wrote:

    Hi all,

    I'm a reasonably experienced puppet user but I'm running into a problem
    with yumrepos where 'before' and 'require' don't seem to be behaving how I
    expect.

    class repos::atomic {
    package { 'atomic-release':
    ensure => installed,
    source => '
    http://www6.atomicorp.com/channels/source/atomic-release/atomic-release-1.0-15.el6.art.noarch.rpm',

    before => Yumrepo['atomic'],
    }

    # After installing the repo, tweak it to limit it to ossec* packages
    yumrepo { 'atomic':
    name => 'atomic',
    includepkgs => 'ossec-hids*',
    require => Package['atomic-release'],
    }
    }

    In theory, this chunk of code installs the atomic-release RPM package,
    which sets up /etc/yum.repos.d/atomic.repo and handles the GPG key. Then,
    my Yumrepo block runs and modifies atomic.repo to add the includepkgs
    line.l

    If the RPM is installed before the Yumrepo, then this works. However,
    quite often it seems the Yumrepo block is run first, creating an
    atomic.repo file with nothing other than the includepkgs line, and then the
    RPM is installed, which notices that atomic.repo exists and creates
    atomic.repo.rpmnew - leaving me with a broken yum configuration.

    This occurs even with the before => Yumrepo['atomic'] and require = >
    Package['atomic-release'] lines in place, which is not what I expect. Am I
    missing a subtlety?

    Cheers,
    Jonathan
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/W7lhnoQOmOwJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Jan 24, 2013 at 8:15 pm

    On Thursday, January 24, 2013 12:11:45 PM UTC-6, Ellison Marks wrote:
    Just my two cents here. I've had some major problems in the past with
    using puppet to manage a file installed by a package which is also managed
    by puppet. Now, I haven't revisited the problem since 2.6, but my intuition
    was that since the file to be managed didn't exist at the start of the run,
    puppet got confused and flubbed the dependencies. My "solution" was to
    handle installing repos when I install the machine, as part of the
    kickstart.
    How odd. It's pretty routine to manage, for example, the package, config
    file, and status of a service with Puppet. There must be thousands of
    manifests exhibiting this general pattern:

    class foo {
    package { 'foo': ensure => installed }

    # Manages a file provided by Package['foo']:
    file { '/etc/foo.conf':
    require => Package[foo],
    content => template('foo.conf.erb')
    }

    # Tweaks a file touched by Package['foo']'s install
    # script:
    service { 'foo':
    enable => true,
    ensure => 'running',
    subscribe => [ Package['foo'], File['/etc/foo.conf'] ]
    }
    }


    And it works, provided that there are no cycles in the relationship graph.
    Whether the physical resources to be managed exist at the beginning of a
    run are immaterial to Puppet. Resource application order is a matter of
    resource definitions in the catalog; the physical resources to which they
    correspond do not factor in to ordering.

    In at least some versions of Puppet, the agent handles relationship cycles
    by choosing a relationship to ignore, thus breaking the cycle. It may be
    that the OP is seeing that behavior. I am anyway inclined to suspect that
    there is more to the picture. Matthew's suggestion to have Puppet generate
    the relationship graph is a good one.

    Also, with respect to providers: Puppet chooses default providers on a
    per-resource-type basis, without regard to the parameters of any given
    resource instance. So, if you want to use the 'rpm' Package provider on a
    yum-based system, then you will need to use the 'provider' parameter to
    tell Puppet so.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/W91EUNv3lYEJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Ellison Marks at Jan 25, 2013 at 12:13 am
    Ah, excuse me, I misremembered. The problem was specific to the interaction
    between package and yumrepo, not package and file. See
    http://projects.puppetlabs.com/issues/1238.
    On Thursday, January 24, 2013 12:15:33 PM UTC-8, jcbollinger wrote:


    On Thursday, January 24, 2013 12:11:45 PM UTC-6, Ellison Marks wrote:

    Just my two cents here. I've had some major problems in the past with
    using puppet to manage a file installed by a package which is also managed
    by puppet. Now, I haven't revisited the problem since 2.6, but my intuition
    was that since the file to be managed didn't exist at the start of the run,
    puppet got confused and flubbed the dependencies. My "solution" was to
    handle installing repos when I install the machine, as part of the
    kickstart.
    How odd. It's pretty routine to manage, for example, the package, config
    file, and status of a service with Puppet. There must be thousands of
    manifests exhibiting this general pattern:

    class foo {
    package { 'foo': ensure => installed }

    # Manages a file provided by Package['foo']:
    file { '/etc/foo.conf':
    require => Package[foo],
    content => template('foo.conf.erb')
    }

    # Tweaks a file touched by Package['foo']'s install
    # script:
    service { 'foo':
    enable => true,
    ensure => 'running',
    subscribe => [ Package['foo'], File['/etc/foo.conf'] ]
    }
    }


    And it works, provided that there are no cycles in the relationship
    graph. Whether the physical resources to be managed exist at the beginning
    of a run are immaterial to Puppet. Resource application order is a matter
    of resource definitions in the catalog; the physical resources to which
    they correspond do not factor in to ordering.

    In at least some versions of Puppet, the agent handles relationship cycles
    by choosing a relationship to ignore, thus breaking the cycle. It may be
    that the OP is seeing that behavior. I am anyway inclined to suspect that
    there is more to the picture. Matthew's suggestion to have Puppet generate
    the relationship graph is a good one.

    Also, with respect to providers: Puppet chooses default providers on a
    per-resource-type basis, without regard to the parameters of any given
    resource instance. So, if you want to use the 'rpm' Package provider on a
    yum-based system, then you will need to use the 'provider' parameter to
    tell Puppet so.


    John
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ywQ4xMczyt0J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jonathan Gazeley at Jan 25, 2013 at 9:54 am

    On 25/01/13 00:13, Ellison Marks wrote:
    Ah, excuse me, I misremembered. The problem was specific to the
    interaction between package and yumrepo, not package and file. See
    http://projects.puppetlabs.com/issues/1238.
    Thanks Ellison for the link. This is exactly what I'm experiencing. I'm
    now watching the bug and for the time being I'll work around the problem
    by not mixing *-release.rpm files with Yumrepo resources.

    Thanks to everyone else who chipped in too.

    Cheers,
    Jonathan

    --
    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 post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 24, '13 at 3:09p
activeJan 25, '13 at 9:54a
posts8
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase