Unfortunately, I do not have a workaround, short of "Don't use the Yumrepo and Package types together".
Does anyone else have a better way to workaround this bug? -= Stefan On Friday, November 13, 2015 at 9:58:26 AM UTC-8, Stefan Lasiewski wrote: > > On Fri, Nov 13, 2015 at 6:36 AM, jcbollinger <John.Bollinger@...> 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 > > > > -- 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/8bc063a1-da4b-4551-98f4-5359c36022a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
