Issue #1238 has been updated by Stijn Hoop.
Jan Ivar Beddari wrote: > First, I wasn't talking about chaining or dependencies, but collections, read > the text around the last code block example of that section. > > <cite>It disregards the fact that the state of the machine can change as the > puppet catalog for the node is evaluated on the node.</cite> > > As a general rule, this is what you want! However, with repo configs the > situation might be not as clearcut. Hence the design decision from three > years ago was to get rid of the prefteching .. the principle of least > astonishment :-) > > Still, it IS easier to get this to work than the number of filed bugs about > this would suggest. Documentation does not tell you clearly that *the yumrepo > provider is an all or nothing solution* > > * As pointed out to get it working stop using repo RPMs and define ALL > yumrepos as resources > * Or manage repos as files and with repo rpms. Jump through some narrow hoops > or don't expect to be installing packages and repos in the same Puppet run. > > Just documenting this better would have solved quite a few issues over the > years. The problem is that the default mode of operations for "extra" repositories depends on installing an RPM which includes the repo configuration. Other packages in that repository may depend on the fact that the -repo RPM is installed (by having a RPM dependency on it). The repo RPM often also contains more than only the canonical repository, such as -debuginfo or SRPM repository locations, but disabled by default. These are often very handy to have present on a system when things go wrong. Furthermore, installing, and more importantly, UPDATING the RPM ensures that the configuration is correct. Not doing it by RPM means that I have to verify (by unpacking the repo RPM by hand, or installing it on a non-puppet test system) that the repository did not switch URLs in a new release. I agree that this will probably be a rare occurrence, but it has happened. So with these two points in mind, I'd argue that NOT installing the repo RPM is not a correct policy to enforce, nor to document on the puppet side. ---------------------------------------- Bug #1238: strange yumrepo/package interaction https://projects.puppetlabs.com/issues/1238 Author: BMDan - Status: Accepted Priority: Normal Assignee: David Lutterkort Category: yumrepo Target version: 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
