[Puppet Users] Re: 'before' and 'require' not working as I expect
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: 'before' and 'require' not working as I expect
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: 'before' and 'require' not working as I expect
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: 'before' and 'require' not working as I expect
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+unsubscr...@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.
