Puppet users - Jan 2013 - 'before' and 'require' not working as I expect

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.

On Thu, Jan 24, 2013 at 2:49 PM,  <jg4461@bristol.ac.uk> 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.

On 24/01/13 15:18, Matthew Burgess wrote:
> On Thu, Jan 24, 2013 at 2:49 PM,  <jg4461@bristol.ac.uk> 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.

On Thu, Jan 24, 2013 at 3:30 PM, Jonathan Gazeley
<Jonathan.Gazeley@bristol.ac.uk> wrote:
> On 24/01/13 15:18, Matthew Burgess wrote:
>>
>> On Thu, Jan 24, 2013 at 2:49 PM,  <jg4461@bristol.ac.uk> 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.

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.

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.

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.

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.