rpm installation ordering question and yum repos

[Vince Skahan]

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' |>

}

[Byron Miller]

I use the "Run stage" pattern for this.. and it is perfect for this use case.. (one of the few times its recommended)

https://docs.puppetlabs.com/puppet/latest/reference/lang_run_stages.html

-byron

[Martin]

We simply use YUM priorities for that:

http://wiki.centos.org/PackageManagement/Yum/Priorities

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/aa22ca14-f478-48f9-bda1-6d5d804ac657%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 

http://www.xing.com/profile/Martin_Marcher
http://www.linkedin.com/in/martinmarcher

Mobil: +43 / 660 / 62 45 103

UID: ATU68801424

[Martin]

Oh I misread the question sorry :) -- Yes the stages is probably the right approach.

/Martin

[jcbollinger]

On Friday, July 24, 2015 at 11:30:34 AM UTC-5, Vince Skahan wrote:

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