| Some resource types can have an effect other types, such as yumrepo and package. In this example, when a package resource is encountered in a catalog, puppet prefetches package version information from the package provider. However, if a yumrepo resource (or perhaps a file resource for apt or ini_setting resource for zypper) then changes the underlying repo that other packages come from, even if that first applied package is entirely unrelated, puppet will not refetch package information and end up using stale information for the application of later package resources. This was the bug in PE-28931. Having a metaparameter, something like invalidate_prefetch or flush_type, that takes a resource type and tells Puppet to flush its cached information for that type and refetch it, would mitigate this problem. It would probably only need to be performed if the resource was applying corrective changes.
file { '/etc/yum.repos.d/foo.repo': |
ensure => present, |
source => 'puppet:///modules/foo.repo', |
invalidate_prefetch => Package, |
} |
While it is possible to ensure, say, yumrepo resources come before all package resources via a resource collector, usage of these collectors is not always ideal (or in the case of PE management code, we can't just collect all packages due to our use of virtual resources). In general, this is a constraint in Puppet's ability to easily model desired state. If one package resource is entirely unrelated to other yumrepo / package resources, it should not have an effect on them. |
