[Yum] Re: yum] Survey of Use

Jim Wildman jim at rossberry.com
Sat Oct 25 00:47:45 UTC 2003


Russ got this pretty close.  Once a machine is turned over to the
production support people, any change to the software (such as
upgrades) must be documented and approved by a change review board,
which includes all the parties who may be 'cross impacted' by the
failure of a particular machine.  (Exceptions are made for fixing
'failures'.)  The specific changes are then approved
for a specific time frame.  If the change fails, then you do a post
mortum and do it all over.  So we can't let yum resolve dependenicies on
the fly on the production machines.  Since we can't use it to just
transfer packages without installing them, we will use other mechanisms
to transfer a predefined list of packages, which will then be installed
during the time window.  We also employ an enterprise scheduling package
which will be used to schedule the actual install/upgrade.  A
missing dependency would be a 'failure'.

On Thu, 23 Oct 2003, R P Herrold wrote:

> I do not know that I saw a reply by Jim Wildman to the 'change
> control' question, but the core concept is that a given client
> host should be able to be pushed (or its yum find and pull)  
> only a tested, 'back-outable', and approved packageset at a
> stated and known EVR.  The 'ad hoc' nature of yum's dependency
> solution for an 'unruly' way most OSS end users is a great
> match; with 'change control' and a defined package set, it is
> also possible to push out transactions (for yum to solve
> against) of just 'permitted' and approved updates to update
> mirrors; this also permits more policy based management of
> hosts.
> 

------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim at rossberry.com
http://www.rossberry.com




More information about the Yum mailing list