Bug 514635 - Unable to see all relevant EUS channels when changing base channel
Summary: Unable to see all relevant EUS channels when changing base channel
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API
Version: 530
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Justin Sherrill
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: sat540-canfix
TreeView+ depends on / blocked
 
Reported: 2009-07-29 22:21 UTC by Sayli Karmarkar
Modified: 2018-10-27 12:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 523818 (view as bug list)
Environment:
Last Closed: 2010-08-31 13:16:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
channels tab (105.70 KB, image/png)
2009-07-29 22:26 UTC, Sayli Karmarkar
no flags Details
changing base channel (88.31 KB, image/png)
2009-07-29 22:26 UTC, Sayli Karmarkar
no flags Details
After registering using EUS 5.3 activation key and trying to change base channel (85.12 KB, image/png)
2009-07-29 22:27 UTC, Sayli Karmarkar
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1172201 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1172201

Description Sayli Karmarkar 2009-07-29 22:21:24 UTC
Description of problem:

Steps to Reproduce:
1. Ensure rhel5 32 bit EUS channels are synced.
2. Register a rhel5.1 system to the satellite. 
3. Try to change base channel of the system. 
  
Actual results:
Only EUS 5.2.z channel is shown in the list of relevant base channels.

Expected results:
There should be 5.1, 5.2 and 5.3 EUS channels in the relevant list. 

Additional info:
If I create an activation-key with EUS rhel5.3 channel and use it to register the same system, it gets registered properly. But again, if I go to change base channel, I can see EUS 5.1 and 5.2 channels as well, which I shouldn't. 

Attaching snapshots.

Comment 1 Sayli Karmarkar 2009-07-29 22:26:04 UTC
Created attachment 355615 [details]
channels tab

Comment 2 Sayli Karmarkar 2009-07-29 22:26:36 UTC
Created attachment 355616 [details]
changing base channel

Comment 3 Sayli Karmarkar 2009-07-29 22:27:23 UTC
Created attachment 355617 [details]
After registering using EUS 5.3 activation key and trying to change base channel

Comment 5 Devan Goodwin 2009-07-30 16:28:21 UTC
Part of this bug isn't actually a bug but working as designed, this has come up many times before so it's understandable but if you're currently subscribed to the mainline RHEL channel, you can only switch to the latest EUS channel. (Will post link to info this was based on in followup priv comment) Only when a system is subscribed to an EUS channel do we do the redhat-release version comparison logic to determine which EUS channels are suitable.

So the bug to me is why is only RHEL 5.2.z showing up when 5.3.z is showing up. This is most likely a problem during Satellite sync, were these channels synced off an old channel dump or anything like that? Any strangeness come to mind during the sync?

Comment 11 Tomas Lestach 2010-01-22 15:08:07 UTC
According to Comment#5 and the provided link, it's clear first part is OK.
Second part (offering EUS 5.2 when EUS 5.3 is available) is a bug. However I am not able to reproduce it.

I registered a RHEL5.1 i386 client to sat53 with synced RHEL EUS 5.x channels:
* RHEL Extended Update Support (v. 5.0.z for 32-bit x86)
* RHEL Extended Update Support (v. 5.1.z for 32-bit x86)
* RHEL Extended Update Support (v. 5.2.z for 32-bit x86)
* RHEL Extended Update Support (v. 5.3.z for 32-bit x86)
* RHEL Extended Update Support (v. 5.4.z for 32-bit x86)

Following base channels are offered to me, when changing base channel:
- from RHEL EL (v. 5 for 32-bit x86):
  * RHEL EUS (v. 5.4.z for 32-bit x86)
- from RHEL EUS5.4:
  * RHEL EL (v. 5 for 32-bit x86)
  * RHEL EUS (v. 5.1.z for 32-bit x86)
  * RHEL EUS (v. 5.2.z for 32-bit x86)
  * RHEL EUS (v. 5.3.z for 32-bit x86)
  * RHEL EUS (v. 5.4.z for 32-bit x86)
what is correct.

I see correct behavior also with clients EL 5.1 and 4.6.

Could you provide more detailed description, how to reproduce it?


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