Issue #1238 has been updated by Charlie Sharpsteen.
Status changed from Investigating to Accepted
Assignee deleted (Charlie Sharpsteen)
So, the issue here is that the yumrepo type does not implement pre-fetching,
but uses a class variable (`@inifile`) to store the contents of all files in
`/etc/yum.repos.d/*.repo` and `/etc/yum/repos.d/*.repo` along with the contents
of `/etc/yum.conf`. The first yumrepo resource to be processed by the agent
populates this data structure and each subsequent resource refers to whatever
was loaded by the first resource.
This is the same behavior you will see with resources that specifically use
prefetching. For example, when managing host entries with the parsedfile
provider, the following manifest creates two new entries in `/etc/hosts`:
<pre>
# cat parsedfile_hosts.pp
exec { '/bin/echo "1.2.3.4 exec_1" >> /etc/hosts': }
->
host { 'host_1': ip => '4.5.6.7' }
# puppet apply parsedfile_hosts.pp
Notice: Compiled catalog for pe-310-agent.puppetdebug.vlan in environment
production in 0.11 seconds
Notice: /Stage[main]//Exec[/bin/echo "1.2.3.4 exec_1" >> /etc/hosts]/returns:
executed successfully
Notice: /Stage[main]//Host[host_1]/ensure: created
Notice: Finished catalog run in 0.42 seconds
# cat /etc/hosts
# HEADER: This file was autogenerated at 2013-11-14 22:32:01 +0000
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1 localhost
127.0.1.1 pe-310-agent.puppetdebug.vlan pe-310-agent
1.2.3.4 exec_1
4.5.6.7 host_1
</pre>
But if we add another host resource that runs before the exec, the effects of
prefetching come into play and the external effects of the exec are lost:
<pre>
# cat prefetched_hosts.pp
host { 'host_1': ip => '1.2.3.4' }
->
exec { '/bin/echo "4.5.6.7 exec_1" >> /etc/hosts': }
->
host { 'host_2': ip => '8.9.10.11' }
# puppet apply prefetched_hosts.pp
Notice: Compiled catalog for pe-310-agent.puppetdebug.vlan in environment
production in 0.10 seconds
Notice: /Stage[main]//Host[host_1]/ensure: created
Notice: /Stage[main]//Exec[/bin/echo "4.5.6.7 exec_1" >> /etc/hosts]/returns:
executed successfully
Notice: /Stage[main]//Host[host_2]/ensure: created
Notice: Finished catalog run in 0.36 seconds
# cat /etc/hosts
# HEADER: This file was autogenerated at 2013-11-14 22:36:58 +0000
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1 localhost
127.0.1.1 pe-310-agent.puppetdebug.vlan pe-310-agent
1.2.3.4 host_1
8.9.10.11 host_2
</pre>
We could look at removing pre-fetching from the Yumrepo type, but a more
fruitful path might be to resolve #8758 and split Yumrepo into a type and
provider. Then people could actually choose to write providers that make
different decisions with respect to things such as prefetching and distribute
those via the forge. I know the maintainers of the augeasproviders module are
interested in this.
In the meantime, a workaround may be to just manage the contents of `*.repo`
files created by the packages instead of using a type that currently expects to
manage both the creation and contents of those files.
This can be done using an Augeas resource:
<pre>
package { 'nginx-release-centos':
ensure => 'present',
provider => 'rpm',
source =>
'http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm',
}
augeas { 'manage nginx repo':
context => '/files/etc/yum.repos.d/nginx.repo/nginx',
changes => [
'set enabled 0',
],
require => Package['nginx-release-centos'],
}
package { 'epel-release':
provider => rpm,
source =>
'http://mirror.us.leaseweb.net/epel/6/i386/epel-release-6-8.noarch.rpm',
ensure => installed,
}
augeas { 'manage epel repo':
context => '/files/etc/yum.repos.d/epel.repo/epel',
changes => [
'set enabled 1',
'set includepkgs "python-virtualenv python-pip"',
],
require => Package['epel-release'],
}
</pre>
This will manage the repo definitions laid down by both the nginx and epel
packages without clobbering either of those files.
----------------------------------------
Bug #1238: strange yumrepo/package interaction
https://projects.puppetlabs.com/issues/1238#change-99901
* Author: BMDan -
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: yumrepo
* Target version: 3.x
* Affected Puppet version:
* Keywords:
* Branch:
----------------------------------------
Yumrepo appears to be checking file existence before allowing the package
command to complete, meaning that it creates a file containing only "[remi]"
and "enabled=1", overwriting the file that the RPM installed.
Manifests, additional debug output, etc., available upon request. Just tell me
what you need to know. Workarounds especially welcomed. Puppet v. 0.24.4,
running with --debug --test, on Ruby 1.8.6.114-1, compiled from source with
default options.
<pre>
debug: //Node[default]/remi_enabled/Yumrepo[remi]/require: requires
Package[remi-release-5-4.el5.remi]
</pre>
...
<pre>
debug: Puppet::Type::Package::ProviderRpm: Not suitable: false value
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm -q
remi-release-5-4.el5.remi --nosignature --nodigest --qf %{NAME}
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}'
debug: /Package[remi-release-5-4.el5.remi]: Changing ensure
debug: /Package[remi-release-5-4.el5.remi]: 1 change(s)
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm -i --oldpackage
http://rpms.famillecollet.com/el5.x86_64/remi-release-5-4.el5.remi.noarch.rpm'
notice: /Package[remi-release-5-4.el5.remi]/ensure: created
info: create new repo remi in file /etc/yum.repos.d/remi.repo
debug: //Node[default]/remi_enabled/Yumrepo[remi]: Changing enabled
debug: //Node[default]/remi_enabled/Yumrepo[remi]: 1 change(s)
notice: //Node[default]/remi_enabled/Yumrepo[remi]/enabled: defined 'enabled'
as '1'
info: Filebucket[/var/lib/puppet/clientbucket]: Adding
/etc/yum.repos.d/remi.repo(18f7009978e772c9c646b9410fa3a8b6)
</pre>
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
