How about chaining the resources, ala
http://docs.puppetlabs.com/puppet/2.7/reference/lang_relationships.html#chaining-arrows
.
Yumrepo <| |> -> Package<| |>
This declared in site.pp should apply globally to all nodes and would avoid
the use of run stages (if I understand it correctly).
J
On Tuesday, 31 December 2013 16:47:33 UTC, David Arroyo wrote:
>
> Our site has several dozen yum repositories. Pushing all yum repositories
> to all servers isn't practical; it hurts performance, some repositories are
> OS-specific, and some repositories cause conflicts with each other (we have
> a ruby187 repo and a ruby 193 repo, for example).
>
> In our current setup, we have one module with all our yumrepos defined
> virtually:
>
> class yumrepos {
> @yumrepo{'puppet':
> …
> }
> @yumrepo{'python26':
> …
> }
> …
> }
>
> And our various modules realize those resources as needed:
>
> class puppet(...) {
> realize Yumrepo['puppet']
> …
> }
>
> However, this requires every package definition to require the Yumrepo
> resource. I can ease the pain with resource defaults, but it doesn't go
> away completely. I have found on puppet 2.7 that virtual resources are
> evaluated in the run stage they are defined in, not the run stage they are
> realized in, so that I can do in site.pp:
>
> stage{'package-setup': before => Stage['main'] }
> class{'yumrepos': stage => 'package-setup' }
>
> Then all yum repositories that a node will use are on the machine before
> any packages are installed. Is this a kosher use of run stages? Am I going
> to be surprised by something I didn't consider? I have only tested this
> behavior in Puppet 2.7 and don't know if it is subject to change in later
> releases. How do others handle this problem?
>
> -David
--
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/8d9ab53a-8f85-4646-baac-ebadd693a094%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.