On Friday, July 24, 2015 at 11:30:34 AM UTC-5, Vince Skahan wrote:
>
> Like many sites, we have internal yum repos that contain our
> internally-created rpms, as well as some other repos that are internal
> mirrors of upstream sites (centos updates, etc.). We're running into an
> ordering issue that I'm looking for what the current suggested best
> practice is....
>
> We cooked up a 'my-mirrors-release' rpm notionally like 'epel-release' or
> 'centos-release' etc. that you'd commonly see. Contents are the
> /etc/yum.repos.d files for the various internal repos, and some /etc/pki
> gpg keys for the repos that have signed rpms. Typical yum repo stuff.
>
> Question is how to ensure that our local mirrors-release rpm installs
> before any other rpms that would need to have the repo defined in order to
> find the rpms therein. In other words we want this rpm installed first.
> Like 'really' first
>
> We're trying to avoid having to specify having the my-mirrors-release rpm
> be installed before rpmXYZ every time we specify a rpm to be installed in
> all the places we might want to specify a package be installed. Looking
> for suggestions for a current best practice (assume puppet 3.8 but if
> there's 4.0 magic, that would be good to know)
>
> One solution we came up with is the bottom line in the code snippet
> below. Is this today's best practice for this kind of thing ? Again -
> we're trying to ensure this 'one' rpm is there before installing later rpms
> that would depend on it. Suggestions ?
>
>
> class myprofiles::my_mirrors { # disable upstream repos yumrepo {
> 'updates': enabled => 0, } # enable our mirrors yumrepo {
> 'my-repos': baseurl =>
> 'http://mirrors.example.com/my-mirrors-release/el6', enabled => 1, }
> package { 'my-mirrors-release': provider => yum, ensure => latest,
> require => Yumrepo['my-repos'], } # Ensure our repositories are installed
> before any other package. # (Otherwise the package may not be found.)
> Package<| title == 'my-mirrors-release' |> -> Package<| title !=
> 'my-mirrors-release' |>
> }
>
>
>
Your approach is precisely what I would have recommended for the problem
you present.
Although run stages can sometimes be put to good use, they also can get you
into trouble. I am no fan of them. In this particular case, the approach
you've chosen is no more complex to express in your manifests than one
involving run stages would be, and it is both more localized and lighter
weight.
John
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/03ff01b4-2ae0-4112-a4a1-ba4133b60a10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
