Bug 506296 - Extended Update Support Logic Problems In SDC and SSM
Extended Update Support Logic Problems In SDC and SSM
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Devan Goodwin
Preethi Thomas
:
Depends On:
Blocks: 456985
  Show dependency treegraph
 
Reported: 2009-06-16 12:11 EDT by Devan Goodwin
Modified: 2009-10-28 15:49 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530-unconfirmed
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-28 15:49:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Devan Goodwin 2009-06-16 12:11:54 EDT
Description of problem:

Removal of the is_default column from rhnReleaseChannelMap has caused several problems for the EUS logic in the web UI, and exposed some pre-existing issues.

There are two major paths to hit this logic, SDC alter channels screen, and SSM alter base channels screen. Will file an example problem from both in this bug, but ideally I hope this will be a placeholder for a complete re-test of the EUS code.

Version-Release number of selected component (if applicable):

Satellite-5.3.0-RHEL5-re20090612.0-i386

How reproducible:

Deterministic.

Problem 1:

Steps to Reproduce:
1. Sync RHEL 5 Server, RHEL 5.3z, RHEL 5.2z
2. Register a RHEL 5.2z system. (can force this with an activation key if the system is new and you don't feel like kickstarting)
3. Navigate to the system -> Details -> Alter Channel Subscriptions
  
Actual results:

Under Red Hat Channels, only the mainline RHEL 5 channel is displayed.

Expected results:

RHEL 5.3.z should appear here as well.


Problem 2:
1. Same channels synced as in problem 1.
2. Register a RHEL 5.2z system.
3. View Systems list, select this system, click Update List button.
4. Navigate to Systems -> System Set Manager -> Channels -> Base Channels

Actual results: 

ISE. Looking at code even once the ISE is fixed (it is caused by a remaining reference to the is_default column) the logic will be broken, likely similar to what is above in Problem 1.

Expected results:

No ISE, and list should contain:
- No Change
- System Default Channel (should sub to RHEL 5 main channel if used)
- RHEL 5.3.z

Additional info:

Apologies for filing two issues at once, there is potentially a whole raft of problems here and all are in need of both development and QA attention. The EUS code now needs a complete re-test. (or will once this is fixed) More details on expected behavior to follow in comments.

Additionally it has been discovered that our logic for comparing RHEL 4 EUS channels was broken, and special logic is now required as RHEL 4 redhat-release rpms have releases (note not rpm release, more like rpm version) like "X" or "X.Y", whereas RHEL 5 and presumably future releases of z-stream channels will have releases like "5.1.0.1" and "5.2.0.2". In the case of RHEL 4 we want to sort based only on the X portion of X.Y, and for RHEL 5 we want the X.Y.Z portion of X.Y.Z.W.
Comment 2 Devan Goodwin 2009-06-17 12:43:43 EDT
Fixed in:

spacewalk.git: ac16f09d0e7c11e67bbe8b3961e70e54f3401e3f
satellite.git: 2a4a6f17828670572aad4ef4919d3483733b83e8

I hope the behavior is sane now. One thing you may notice, if you sub a say 4.7z channel to Satellite, then subscribe it to 4.8z but *dont* do the updates, the SDC will still show 4.7z as a channel available for switching too, whereas the SSM will not. This is because in the SDC we can efficiently look at the server's installed redhat-release package and see that it's old enough to stay on 4.7z. In the SSM we're dealing with multiple systems grouped together based on current base channel, and it's not plausible to do this here both for performance and user experience reasons.

Commit includes extensive unit tests that should cover off a bunch of edge cases we can't even reproduce with the EUS channels that exist today.

Hopefully everything else will be ok, the SSM still is a little silly with "System Default Base Channel" but it works, even if it doesn't always tell you what it is. (been like this forever afaik)
Comment 3 Devan Goodwin 2009-06-30 11:11:30 EDT
In comments for bug #505616 Michael seemed to uncover a situation where his RHEL 4 system did not see any option to switch to 4.8.z in the SDC, despite having the channel synced and EUS entitlements.

Michael could you provide any background on how you got to this state and if possible the following:

1. contents of rhnReleaseChannelMap and rhnDistChannelMap
2. add: "log4j.logger.com.redhat.rhn.manager.system.SystemManager=DEBUG" to /usr/share/tomcat5/webapps/rhn/WEB-INF/classes/log4j.properties, then watch catalina.out and visit the SDC alter channels page.

Thanks.
Comment 4 Michael Mráka 2009-06-30 16:11:50 EDT
So... problem 3:
1. sync RHEL4 channel
2. register rhel4.7(!) client (to it's default channel thus RHEL4, no EUS channel available yet)
3. alter channel subscriptions for rhel4.7 client (e.g. add rhn-tools channel)
4. sync RHEL4.6.z, RHEL4.7.z, RHEL4.8.z 
5. subscribe rhel4.7 client to a z-stream channel through alter channel subscriptions page
    https://satellite/rhn/systems/details/SystemChannels.do?sid=XXX
5. select rhel4.7 system,  manage through ssm -> channel membership -> base channels and switch it to z-stream equivalent channel.  
  https://satellite/rhn/channel/ssm/BaseChannelSubscribe.do

Actual results: 
no EUS channel available in steps 4. and 5.

Expected results:
can see and alter base channel to one of EUS channels
Comment 5 Michael Mráka 2009-06-30 16:39:43 EDT
Error reproduced on freshly installed satellite (problem 3 plan from comment #4)

> 1. contents of rhnReleaseChannelMap and rhnDistChannelMap

SQL> select * from rhnReleaseChannelMap;
no rows selected

> 2. add: "log4j.logger.com.redhat.rhn.manager.system.SystemManager=DEBUG" to
> /usr/share/tomcat5/webapps/rhn/WEB-INF/classes/log4j.properties, then watch
> catalina.out and visit the SDC alter channels page.

added debug and restarted whole satellite

reload of https://xen74/rhn/channel/ssm/BaseChannelSubscribe.do
tail -f /var/log/tomcat5/catalina.out

Jul 1, 2009 12:36:35 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 63356 ms
2009-07-01 00:37:25,776 [TP-Processor3] WARN  com.redhat.rhn.frontend.servlets.LocalizedEnvi
ronmentFilter - timezone still null
2009-07-01 00:37:29,819 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:29,819 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:30,036 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:30,978 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:30,978 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:31,010 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.
2009-07-01 00:37:31,032 [TP-Processor3] WARN  com.redhat.rhn.common.db.datasource.DataList - mode or elaborator params is null. When these are null, DataList functions exactly the same as ArrayList.

reload of https://xen74/rhn/systems/details/SystemChannels.do?sid=1000010000
tail -f /var/log/tomcat5/catalina.out
2009-07-01 00:38:10,222 [TP-Processor3] WARN  com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter - timezone still null
2009-07-01 00:38:56,595 [TP-Processor3] WARN  com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter - timezone still null
2009-07-01 00:39:36,496 [TP-Processor2] WARN  com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter - timezone still null
Comment 6 Devan Goodwin 2009-06-30 17:16:42 EDT
Anything unusual about how you were syncing channels? (inter-satellite perhaps?) rhnReleaseChannelMap should *not* be empty if you've synced EUS channels.

Michael, how about rhnDistChannelMap?

Prad any idea what could cause this?
Comment 7 Michael Mráka 2009-06-30 17:41:53 EDT
It's disconnected satellite synced via satellite-sync & disk dump (from satellite 5.2).

SQL> select * from rhnDistChannelMap;
OS
----------------------------------------------------------------
RELEASE                                                          CHANNEL_ARCH_ID
---------------------------------------------------------------- ---------------
CHANNEL_ID
----------
Red Hat Linux
4AS                                                                          500
       101
Comment 8 Devan Goodwin 2009-07-02 08:15:26 EDT
Ok coming from a disk dump I strongly suspect this is why your rhnReleaseChannelMap is empty, and in this state EUS definitely will not work. 

Prad, would you say this is related to bug #506264, or a new issue?
Comment 10 Preethi Thomas 2009-07-07 17:14:15 EDT
looks like this is verified.
rhel4u7 system
registered to the the default.
SDC shows rhel4u8z as an option.
alter channel to rhel4u8
now if you go back to see SDC-> software-> software channels 
both 4u8 & 4u7 are available.

SSM only has 4u8z as expected.


will test with rhel4u6 and rhel5u2
Comment 11 Preethi Thomas 2009-07-07 20:48:08 EDT
looks like this is verified.
rhel4u7 system
registered to the the default.
SDC shows rhel4u8z as an option.
alter channel to rhel4u8
now if you go back to see SDC-> software-> software channels 
both 4u8 & 4u7 are available.

SSM only has 4u8z as expected.


will test with rhel4u6 and rhel5u2
Comment 12 Preethi Thomas 2009-07-07 21:15:21 EDT
rhel4u6 client
registered to default channel
from SDC only default & rhel4u8 are available to change to.
once you change to rhel4u8 then  rhel4u6, rhel4u7, rhel4u8 are available to change to.

SSM has only rhel4u8 available when the client is subscribed to.
if you subscribe to rhel4u6 from sdc and then go to channels in ssm, rhel4u7 and rhel4u8 are available.
Comment 13 Preethi Thomas 2009-07-08 10:02:30 EDT
Devan,
Please read the comments above and let me know if this is the expected behavior so that I can mark the bug accordingly.

thanks
Comment 14 Devan Goodwin 2009-07-08 10:53:16 EDT
This behaviour all looks correct and expected, including the SSM behaviour for 4.6.z.
Comment 15 Preethi Thomas 2009-07-08 13:15:45 EDT
moving to verified as per above comments
Satellite-5.3.0-RHEL5-re20090702.0-i386-embedded-oracle.iso

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