On Fri, Nov 13, 2015 at 6:36 AM, jcbollinger <[email protected]> wrote: > > > That chain of events seems unlikely. In the first place, I'm not prepared > to believe that when applying a catalog corresponding to the declarations > you presented, the agent fails to successfully apply > Package['remi-release'] before it applies Yumrepo['remi-safe']. If you > truly observe such behavior -- via the agent's log output, for example -- > then it follows that the catalog applied was not built based on those > declarations. >
Thanks for that sanity check. Now that I read the logs more closely, I was mistaken. > Under some circumstances, however, the RPM's version of the files might be > installed with an additional .rpmnew extension to avoid replacing > pre-existing versions of the same file. > That is my understanding as well. However, these .rpmnew files aren't being created either, which is strange. If I remove the Yumrepo resource from my manifest, the .rpmnew files will be created if I create a remo-safe.repo file by hand. It is conceivable that your Yumrepo resource is clobbering unmanaged > properties of the managed repository. That would constitute a bug and a > regression, and you can test for it by installing the release package > manually, verifying it good, and then applying the specified class to the > node and observing damage to the repo definition. There are any number of > other possibilities, but I decline to speculate further. > I think I ran into a longstanding bug with the Yumrepo resource type: * https://tickets.puppetlabs.com/browse/PUP-723 "Due to prefetching, Yumrepo clobbers any definition that it does not create" * Historical data is in https://projects.puppetlabs.com/issues/1238 At the head of my log output I see that Puppet is prefetching some Yum resources: Info: Applying configuration version '1447376917' Debug: Prefetching yum resources for package ... ... and further down, it executes the Yumrepo type with cached content: Debug: Executing '/usr/bin/yum -d 0 -e 0 -y list remi-release' Debug: Package[remi-release](provider=yum): Ensuring => latest Debug: Executing '/usr/bin/yum -d 0 -e 0 -y install remi-release' Notice: /Stage[main]/stefanl_yum::Remi/Package[remi-release]/ensure: created Debug: /Stage[main]/stefanl_yum::Remi/Package[remi-release]: The container Class[stefanl_yum::Remi] will propagate my refresh event Notice: /Stage[main]/stefanl_yum::Remi/Yumrepo[remi-safe]/ensure: created Debug: /Stage[main]/stefanl_yum::Remi/Yumrepo[remi-safe]: The container Class[stefanl_yum::Remi] will propagate my refresh event >From reading the bug, it looks like what is actually happening here might be: 1. yumrepo prefetches a yum resource. At this point, the /etc/yum.repos.d/remi*.repo files don't exist, so yumrepo assumes that the files won't exist later. 2. Later, Package[remi-release] is created 3. Then, Yumrepo[remi-safe] is created. But Yumrepo doesn't check for the existence of the remi-safe.repo file first. Instead of adding the parameters to the existing file, it replaces the whole file with the cached content from #1, which is surprising. So, my manifest *does* install things in the order I was expecting. Yumrepo also adds an unexpected surprise at the end. That's my guess anyways. Thanks for the tips John. -= Stefan -- Stefan Lasiewski Email: [email protected] Computer System Engineer III Email: [email protected] Networking, Security, and Servers Group National Energy Research Scientific Computing Center (NERSC <http://nersc.gov>) Lawrence Berkeley National Laboratory -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAK2P-iPdXOL2%3DLyH5p1Ggg%3DvM_rmzOQme-JCkkPPZzmeN%2BJcHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
