[prev in list] [next in list] [prev in thread] [next in thread] 

List:       npaci-rocks-discussion
Subject:    [Rocks-Discuss] Re: rocks upgraders :: torque rpm in epel
From:       Philip Papadopoulos <philip.papadopoulos () gmail ! com>
Date:       2015-04-24 18:09:53
Message-ID: CACnkd5j6xetW6H6p=b=pi7YSvpAjpKUUOCff5=ez4-Hab9EzvQ () mail ! gmail ! com
[Download RAW message or body]

rolls enable you to -precisely- control your local repo. The main reason
for that is exactly what you just ran into -- some external source changed
something that you didn't know about and now things are bad.     You asked
for a blind update, and you received a package in addition.

You can have rolls that are pure package (that's what the OS roll is, just
packages).
You can have rolls that are pure configuration (no RPMS, except the graph
rpm for the roll)
and most rolls have both.

My suggestion for production clusters is rather than blindly update your
cluster from an external repo that isn't the OS base or updates repo, that
you not be cavalier.  If you've pulled a package from epel and want to
update it, use yumdownloader to get the new package and resolve the (new)
dependencies. at least the dependency chaining will be limited to the
package you want to update and you won't get other updates that you didn't
want..  The perfSONAR roll is actually built this way. It's pulls in the
epel dependencies at build time rather than blindly requiring a cluster to
have epel enabled for all other packages.

If you blindly pull all updates from epel, you run the risk of exactly what
you found. Changing rolls into repos doesn't even address that issue.  You
still have a repo that is giving you a conflict.  You have decide if you
want torque from epel or torque from the torque roll.      And if you
changed the torque roll to a torque repo, you'd have to decide if you
wanted torque from the torque repo or the epel repo.  If you don't actively
make that decision, yum will give you it's best guess.

You are certainly taking a leap of faith that the person who created the
torque RPM for the torque roll is anyway compatible with the torque RPM in
epel. They share a name. That's it (they might have the same developer, but
probably do not).   Compile flags, where packages are laid out in the file
system could be completely different. Hence the "configuration" in the
roll may be completely non-sensible if you tried to apply it to the RPM
from epel.



On Fri, Apr 24, 2015 at 7:06 AM, Adrian Sevcenco <Adrian.Sevcenco@cern.ch>
wrote:

> Just a heads up for upgraders : it seems that some (newer) versions of
> torque appeared in epel repo that overwrites the rocks torque. (and now
> i have to clean up the mess of yum -y :( )
> 
> Given that a lot of packages became readily available in usual repos
> i was thinking that maybe the packages and their configuration should
> became separate (to not have rolls but repos) and the actual activity
> of installing a cluster to be just the actual configuration scripts pull
> the packages from active repos and then configure everything..
> 
> Adrian
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2272 bytes
> Desc: S/MIME Cryptographic Signature
> Url :
> http://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20150424/d60581eb/attachment.bin
>  
> 


-- 
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20150424/17733683/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]