Bug 1065483 - Package upgrading using SSM is not host-specific anymore (installs new pkgs on systems)
Summary: Package upgrading using SSM is not host-specific anymore (installs new pkgs o...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 2.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On: 1052051
Blocks: space21
TreeView+ depends on / blocked
 
Reported: 2014-02-14 18:34 UTC by Stephen Herr
Modified: 2014-03-04 13:09 UTC (History)
3 users (show)

Fixed In Version: spacewalk-java-2.1.152-1
Doc Type: Bug Fix
Doc Text:
Clone Of: 1052051
Environment:
Last Closed: 2014-03-04 13:08:14 UTC
Embargoed:


Attachments (Terms of Use)

Description Stephen Herr 2014-02-14 18:34:42 UTC
+++ This bug was initially created as a clone of Bug #1052051 +++

Description of problem:

When a System Set is created with all the same type of hosts (i.e. RHEL6), but which individually have different package-sets, packages which should be installed on one host end up on all other hosts in the set. It does not seem to be unique anymore. 

Example:

zsh is installed on one host and an update is available; another host does not have zsh installed but after the run it is installed.

How reproducible:

Reproducible

Steps to Reproduce:
1. In System Set Manager, schedule the packages that will be updated to 2 
   RHEL6 systems (System1 and System2). For example, the following packages 
   are selected:

   ca-certificates-2013.1.95-65.1.el6_5
   systemtap-2.3-4.el6_5
   systemtap-client-2.3-4.el6_5
   systemtap-devel-2.3-4.el6_5
   systemtap-runtime-2.3-4.el6_5

2. In System Set Manager> Packages>Upgrade> 
   the following are listed to be applied:
 
   System1          ca-certificates-2013.1.95-65.1.el6_5  
                    systemtap-runtime-2.3-4.el6_5
   System2          ca-certificates-2013.1.95-65.1.el6_5
                    systemtap-2.3-4.el6_5
                    systemtap-client-2.3-4.el6_5
                    systemtap-devel-2.3-4.el6_5
                    systemtap-runtime-2.3-4.el6_5

3. After the run, System1 has all of the 5 packages installed.


Actual results:

System1 is installed with the following packages:

ca-certificates-2013.1.95-65.1.el6_5
systemtap-2.3-4.el6_5
systemtap-client-2.3-4.el6_5
systemtap-devel-2.3-4.el6_5
systemtap-runtime-2.3-4.el6_5


Expected results:

System1 should only have 2 packages updated:

ca-certificates-2013.1.95-65.1.el6_5  
systemtap-runtime-2.3-4.el6_5

System1 is not installed with the following packages, so they should not be updated:

systemtap-2.3-4.el6_5
systemtap-client-2.3-4.el6_5
systemtap-devel-2.3-4.el6_5

--- Additional comment from Stephen Herr on 2014-02-14 13:31:51 EST ---

Note:

This behavior only occurs if both systems actually need packages to be updated. If one system has no updates entirely, then no packages will be installed on it. A more full reproducer then is:

1) have two systems, one which has an outdated tcsh and does not have zsh installed, and one which has an outdated tcsh and zsh
2) use system set manager to schedule an update to those two packages
3) not that the webui says it will do the correct thing
4) run rhn_check on each, notice that zsh got install on the first server when it should not have been

Comment 1 Stephen Herr 2014-02-14 18:46:23 UTC
Committed to Spacewalk master:
bc4d195bb51950c1bd14bf48df5d68fbad740d3d

Comment 2 Matej Kollar 2014-03-04 13:08:14 UTC
Spacewalk 2.1 has been released.
https://fedorahosted.org/spacewalk/wiki/ReleaseNotes21

Comment 3 Matej Kollar 2014-03-04 13:09:03 UTC
Spacewalk 2.1 has been released.
https://fedorahosted.org/spacewalk/wiki/ReleaseNotes21


Note You need to log in before you can comment on or make changes to this bug.