Bug 1505985

+++ This bug was initially created as a clone of Bug #1466006 +++

Description of problem:

For a system subscribed to RHEL 7.2 EUS channel, "Alter Channel Subscription" does not list RHEL 7.3 EUS channel as a available channel. The only option displayed is RHEL 7 Server base channel.

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

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL 7.2 system (redhat-release-server package v 7.2 should be installed on the system)
2. Sync RHEL 7.2 EUS and 7.3 EUS channels on satellite server. 
3. Register the system using rhn_register and associate RHEL 7.2 EUS base channel 
4. From webui try to change the base channel to RHEL 7.3 EUS 

Actual results:

RHEL 7.3 EUS channels is not available on "Alter Channel Subscription" other than RHEL 7 base Server channel

Expected results:

RHEL 7.3 EUS channels should be available on "Alter Channel Subscription" along with RHEL 7 Server base channel. 

Additional info:

--- Additional comment from Ashish Humbe on 2017-06-28 13:10:24 EDT ---

Additional Information:

This issue is reproducible locally: 


https://<satellite>/rhn/systems/details/SystemChannels.do?sid=XXXX


While checking the output of db queries executed in backend, I see both EUS channels are listed: 

select distinct c.id,
               c.label,
               c.name,
               rcm.release,
               0 AS IS_CUSTOM
        from
            rhnChannelPermissions cp,
            rhnChannel c,
            rhnServerArch sa,
            rhnServerChannelArchCompat scac,
            rhnReleaseChannelMap rcm,
            rhnProductName pn
        where
            rcm.version = '7Server'
            and scac.server_arch_id = sa.id
            and sa.label = 'x86_64-redhat-linux'
            and scac.channel_arch_id = rcm.channel_arch_id
            and rcm.channel_id = c.id
            and cp.channel_id = c.id
            and cp.org_id = 1
            and pn.id = c.product_name_id
            and pn.label = 'rhel'
            and rhn_channel.loose_user_role_check(c.id, 1,
                                                     'subscribe') = 1
        order by c.name; 

 id  |           label            |                    name                    |  release  | is_custom 
-----+----------------------------+--------------------------------------------+-----------+-----------
 131 | rhel-x86_64-server-7.2.eus | RHEL EUS Server (v. 7.2 for 64-bit x86_64) | 7.2-9.el7 |         0
 128 | rhel-x86_64-server-7.3.eus | RHEL EUS Server (v. 7.3 for 64-bit x86_64) | 7.3-1.el7 |         0
(2 rows)


Not sure why those are note listed in the webui.

--- Additional comment from Grant Gainey on 2017-06-28 13:16:27 EDT ---

Is this a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1442313#c6 ? 7.3 EUS metadata was broken earlier this year, if the broken data was *ever* sync'd, it requires deleting the 7.3EUS channel and resynching to fix.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1427354

--- Additional comment from Ashish Humbe on 2017-06-28 13:29:04 EDT ---

Hi Grant,

Thank you for the update,

I had discussion with Tomas Lestach about this issue, he cross checked few things on the setup and agreed to create bz for same. 

This issue is reproducible locally and also at customer end. We tried removing and re-syncing channels on the customers satellite but there was no change. The mapping in the rhnReleaseChannelMap table is correct.

One more thing I would like to share is, when we downgrade the redhat-release-server package to v 7.1 the RHEL 7.2 EUS , RHEL 7.3 EUS and RHEL 7 Server base channels are available on "Alter Channel Subscription" page. From this I think we can confirm that the mapping is correctly reflected...


Regards,
Ashish

--- Additional comment from Tomas Lestach on 2017-08-25 04:20:22 EDT ---

Actually I see a very similar problem on <satellite>, what is Sat 5.8.

A system with redhat-release-server-7.2-9.el7 will be offered to be subscribed to:
* RHEL EUS Server v7.3 if currently in RHEL Server v.7
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.3
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.2
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.1

My understanding is following:
A system with redhat-release-server-7.2-9.el7 should be offered to be subscribed to:
* RHEL EUS Server v7.2 (AND RHEL EUS Server v. 7.3) if currently in RHEL Server v.7
* RHEL Server v.7 AND RHEL EUS Server v. 7.3 if currently in RHEL EUS Server v7.2
* RHEL Server v.7 AND RHEL EUS Server v. 7.3 AND RHEL EUS Server v7.2 if currently in RHEL EUS Server v. 7.1


Let's investigate the issue and clarify, if the expectations are incorrect.

--- Additional comment from Grant Gainey on 2017-08-29 16:03:21 EDT ---

The EUS-subscription-logic is based on two things:

* what does the redhat-release RPM *currently on the system* say the system 'is'?
* what base-channel is the system currently subscribed to?

The allowed base-channel changes should be as follows, for a system whose *redhat-release RPM* is X.Y (note that you can always change to any custom-base-channel)

* subscribed to BaseX?
 * can change to BaseX.max(N)

* subscribed to BaseX.n?
 * can change to any X.N, where N >= Y, or to RHEL BaseX
 * example: redhat-release says 7.2 EUS, 7.4 is max, subscribed to RHEL7.3 - can move to 7.[234]

* subscribed to custom channel?
 * can change to RHEL BaseX

Basically, the webUI logic is based around the assumption that going 'backwards' from the installed redhat-release RPM is likely to result in an unstable system, and doesn't allow it.

With RHEL7, the way version and release can be found from the redhat-release RPM changed in ways that broke the RHEL4/5/6 heuristics. The fix for https://bugzilla.redhat.com/show_bug.cgi?id=1282474 (q.v.) was incorrect/incomplete - but in a way that 'worked' for RHEL7.0, .1, and .2. It wasn't until 7.3 that the problem started to bite us.

--- Additional comment from Grant Gainey on 2017-08-29 16:27:34 EDT ---

(note error in #c5 - from custom, you should be able to get to "any X.N, where N >= Y, or to RHEL BaseX")

--- Additional comment from Grant Gainey on 2017-08-29 16:28:51 EDT ---

spacewalk.github:
dc92c9a008bbf2583d1b2b99e4ab592089eae56c

--- Additional comment from Pavel Studeník on 2017-09-21 11:14:12 EDT ---

I look that I can't register system rhel7.0+ to EUS with parameter "--use-eus-channel" by rhnreg_ks.

function s.registration.available_eus_channels(username, password, server_arch, server_version, server_release) return empty result. I suppose that it can be problem of backend, not client. I need check it due to cdn mapping.

The RHEL6 works good.

Is it possible that this issue related with my problem?

--- Additional comment from Grant Gainey on 2017-09-21 11:30:42 EDT ---

(In reply to Pavel Studeník from comment #8)
> I look that I can't register system rhel7.0+ to EUS with parameter
> "--use-eus-channel" by rhnreg_ks.
> 
> function s.registration.available_eus_channels(username, password,
> server_arch, server_version, server_release) return empty result. I suppose
> that it can be problem of backend, not client. I need check it due to cdn
> mapping.
> 
> The RHEL6 works good.
> 
> Is it possible that this issue related with my problem?

This BZ is for the behavior on the web-ui side of things, which is the Java stack.

Registration is entirely in the python code - so even if there exists a 'rhel7-eus-registration' issue, it's a completely different codebase. Also, the issue we're talking about here only bites Sat5 in RHEL7.3+ - if you're having trouble registering to EUS with RHEL7.0/1/2, then Something Else went worng.

--- Additional comment from Tomáš Kašpárek on 2017-10-11 05:13:05 EDT ---

satellite.git(SATELLITE-5.7): 2463b96afae39b665f195b59af3445534aac664a

--- Additional comment from errata-xmlrpc on 2017-10-11 05:54:02 EDT ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2017:30890-01
https://errata.devel.redhat.com/advisory/30890

--- Additional comment from Martin Korbel on 2017-10-18 06:37:07 EDT ---

I tried to verified this fix. But I think it still does not work. 

My reproducer:
1. I synced RHEL 7.2 eus & 7.3 eus via intersync from <satellite>.
2. I have client machine with RHEL 7 (via 5minute)
3. I created Activation Key on satellite and setup RHEL 7.2 eus for this key. 
4. I registered this client machine by Activation key.
5. When I open the detail of this client, I see "RHEL EUS Server (v. 7.2 for 64-bit x86_64)" as subscribed channel. But when I try to change it, I see only "RHEL Server (v. 7 for 64-bit x86_64)". 


--- Additional comment from Grant Gainey on 2017-10-18 08:14:41 EDT ---

(In reply to Martin Korbel from comment #12)
> I tried to verified this fix. But I think it still does not work. 
> 
> My reproducer:
> 1. I synced RHEL 7.2 eus & 7.3 eus via intersync from <satellite>.
> 2. I have client machine with RHEL 7 (via 5minute)
> 3. I created Activation Key on satellite and setup RHEL 7.2 eus for this
> key. 
> 4. I registered this client machine by Activation key.
> 5. When I open the detail of this client, I see "RHEL EUS Server (v. 7.2 for
> 64-bit x86_64)" as subscribed channel. But when I try to change it, I see
> only "RHEL Server (v. 7 for 64-bit x86_64)". 
> 


I will retest on my system, pretty sure I tested 7.2-to-7.3 and -7.4 but will recheck. If it works4me there, then it's possible we're dealing with a different issue.

Also - please note #c2 - if 7.3 was sync'd when the 7.3 metadata was broken, the only way to fix the resulting problems was to delete the 7.3 channel and resync. I can't imagine that we're still suffering from that, but it's one thing that was clouding the eus-issue for a very long time.

--- Additional comment from Grant Gainey on 2017-10-18 10:15:55 EDT ---

(In reply to Martin Korbel from comment #12)
> I tried to verified this fix. But I think it still does not work. 
> 
> My reproducer:
> 1. I synced RHEL 7.2 eus & 7.3 eus via intersync from <satellite>.
> 2. I have client machine with RHEL 7 (via 5minute)

The 5minute client images comes w/this redhat-release RPM:
[root@<client> ~]# rpm -qa | grep release
redhat-release-server-7.3-7.el7.x86_64

As noted in #c5 - the installed redhat-release RPM is the controlling feature in this logic. Your redhat-release X.Y is 7.3. That means the "what can I subscribe to" logic will let you go to 7Base, or any 7.n EUS channel where n is *greater than* 3. You therefore should only be able to go to 7.4, or 7Base, only.

Maybe we need to make that a >=. Or maybe this is a never-happen case, because I'm not sure what it means to subscribe a 7.3 system, to a 7.2 channel in the first place. All your 7.3 system's RPMs are going to be newer than anything in 7.2, and you will never see any updates.

The code appears to be working-as-designed, but a) I will do some more experimenting, and b) I am willing to be convinced that maybe we need to loosen the restriction here. There's no actual documentation anywhere on what it means to switch between EUS channels, and never has been, alas.

--- Additional comment from Grant Gainey on 2017-10-18 11:26:29 EDT ---

Martin - further experimentation shows that *something* is wrong here. Mark as fails-qa please, will continue investigating till I find out what went wrong.

--- Additional comment from Grant Gainey on 2017-10-19 15:34:24 EDT ---

Martin - So where I am right now:

Scenario:

* <satellite>
* <client>

* sync 7.1 and 7.4

I have registered this client with an AK to 71 (1-rhel71) and just to its base. Current profile is AK-RHEL7EUS-TEST.  

I have replaced its existing 7.2 redhat-release-server RPM with both the 7.1 version and the 7.4 version.

1) Subscribed to Base? Base and 7.4 available (can only move to highest-EUS from Base)

2) Subscribed to 7.1, redhat-release says 7.1? Can move to 7.1, 7.4, Base (can only move 'up' the chain)
3) Subscribed to 7.4, redhat-release says 7.1? Same. (redhat-release is controlling, not "which EUS-channel are you subscribed to?")

4) Subscribed to 7.1, redhat-release says 7.4? Can move *only to Base*
5) Subscribed to 7.4, redhat-release says 7.4? Same. (redhat-release is controlling, not "which EUS-channel are you subscribed to?")

So - your client's redhat-release-server says it's a 7.3 system, there is no 7.4 on your test satellite. When subscribed to a 7.2 channel, you're in scenario-4, above.

In both 4 and 5, I think I should be able to subscribe to 7.4 - that's what my redhat-release-server says. This suggests that there really may be a '>' that needs to be a '>='.

Does any of this make sense to you?

--- Additional comment from Grant Gainey on 2017-10-24 13:55:09 EDT ---

RHEL7EUS versioning, in the rhNReleaseChannelMap table, didn't match RHEL5 or RHEL6. It also didn't match (at the PackageEvr.toString() level) at the package-level. The initial fix for this problem made a bad assumption about consistency.

Sample from rhnReleaseChannelMap:

rhnschema=# select * from rhnreleasechannelmap order by release;
     product     | version |  release  | channel_arch_id | channel_id 
-----------------+---------+-----------+-----------------+------------
 RHEL EUS Server | 7Server | 7.1-1.el7 |             508 |        118
 RHEL EUS Server | 7Server | 7.2-9.el7 |             508 |        131
 RHEL EUS Server | 7Server | 7.3-1.el7 |             508 |        130
 RHEL EUS Server | 7Server | 7.4-1.el7 |             508 |        121

redhat-release-server packages:

redhat-release-server-7.1-1.el7.x86_64.rpm
redhat-release-server-7.2-9.el7.x86_64.rpm
redhat-release-server-7.3-7.el7.x86_64.rpm
redhat-release-server-7.4-18.el7.x86_64.rpm

7.3-7 != 7.3-1, 7.4-18 != 7.4-1. PackageEvr.toString() return [epoch.]version.release, which complicates things even more.

SATELLITE-5.7:
a3e7cdbe3df01d1f515922a5c44b7760c9941b3b

This fix will likely needs to be done in the next 5.8 erratum as well, I believe the code there is also wrong.