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.
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)
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.
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
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
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?
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
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?
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
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.
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
This behaviour all looks correct and expected, including the SSM behaviour for 4.6.z.
moving to verified as per above comments Satellite-5.3.0-RHEL5-re20090702.0-i386-embedded-oracle.iso