Bug 1313676

Summary:	no way in webUI how to switch to EUS channel if you have mistakenly switched to main channel
Product:	Red Hat Satellite 5	Reporter:	Jan Hutař <jhutar>
Component:	WebUI	Assignee:	Grant Gainey <ggainey>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	570	CC:	dyordano, ggainey, tlestach
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-03 07:59:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Hutař 2016-03-02 08:09:11 UTC

Description of problem:
There is no way in webUI how to switch to EUS base channel if you have mistakenly switched to main (X-stream) channel or to custom channel or to none channel.


Version-Release number of selected component (if applicable):
spacewalk-java-2.3.8-123.el6sat.noarch


How reproducible:
always


Steps to Reproduce:
1. Register system redhat-release-server-6Server-6.4.0.4.el6.x86_64 with:
   # rhnreg_ks --force --username=admin --password=nimda --use-eus-channel
2. Ensure you have e.g. these channels synced on your Satellite:
   rhel-x86_64-server-6.4.z
   rhel-x86_64-server-6.6.z
   rhel-x86_64-server-6
   (note that in my testing it did not worked when synced with "--no-packages")
3. In Systems -> <system> -> Software -> Channels Channels -> Base Software
   Channel it offers custom channels + "(none, disable service)" and 6.4.z,
   6.6.z and 6 channels
4. Switch to some custom channel or to ...-6 channel or to "(none, disable
   service)"


Actual results:
Now, no EUS channel is offered.


Expected results:
When we are in custom channel or "(none, disable service)", we should offer EUS channel (see Grant's note in bug 1282474 comment #15).


Additional info:
As a workaround you can just re-register with command stated above.

Comment 1 Tomas Lestach 2016-03-02 11:29:11 UTC

According to my knowledge the correct way to go from a custom to an EUS channel is over the default non-eus channel, so:

custom channel -> rhel-x86_64-server-6 -> rhel-x86_64-server-6.4.z

JanH, can you confirm, this scenario does not work?

Comment 2 Grant Gainey 2016-03-02 12:07:14 UTC

Yeah, something definitely seems wrong here - I'll do some testing when I get in as well.

Comment 3 Tomas Lestach 2016-03-02 12:34:31 UTC

Actually, this Comment#1 scenario works for me in upstream.

Comment 4 Jan Hutař 2016-03-02 18:52:40 UTC

(In reply to Tomas Lestach from comment #1)
> According to my knowledge the correct way to go from a custom to an EUS
> channel is over the default non-eus channel, so:
> 
> custom channel -> rhel-x86_64-server-6 -> rhel-x86_64-server-6.4.z
> 
> JanH, can you confirm, this scenario does not work?

Yep, that does not work for me as well :-/

Comment 5 Grant Gainey 2016-03-02 20:01:01 UTC

The overall requirement for switching base-channels on an EUS-system is, "You can only move up". Up, in this case, is based on the redhat-release-server RPM on the client in question.

'none' and 'custom' only let you go to 'base-rhel' (because we have no idea what you might have done to them, so 'latest' is the assumption)

Once your base-channel has been switched to 'base-rhel', you can only be switched to the highest-level EUS channel available.

Switching to an EUS base-channel, lets you then switch to any EUS channel *greater than or equal to* that supported by your redhat-release-server RPM.

Once you update your redhat-release-server RPM, you're now a different EUS than you were before, and have a different choice of channels.

So, assume the following:

* Sat5 that has 6.4, 6.6, 6.7, and 6-base, and a custom channel.
* A client, '6_4', with redhat-release-server-6Server-6.4.0.4.el6
* A client, '6_6', with redhat-release-server-6Server-6.6.0.2.el6

6_4 should be able to switch from 6.4.0 to 6.6, 6.7, base, custom, and none
6_6 should be able to switch from 6.6.0 to 6.7, base, custom, and none

Either, switched to 'base-rhel', should only allow switching to 6.7

6_4, switched to 6.7, should then allow you to go to 6.4, 6.6, 6.7, or base-rhel

6_6, switched to 6.7, should then allow you to go to 6.6, 6.7, or base-rhel

All of this is the behavior I see on my test-system.

I won't ask if this 'makes sense', because it kind of doesn't, but it's the way it's been since EUS was invented in 2007. If this is what we're seeing, then this BZ should be closed as NOTABUG.

Comment 7 Jan Hutař 2016-03-03 07:59:25 UTC

Ah, OK, you are absolutely right:

Satellite(@Oracle) with 5, 5.9.z, 6, 6.4.z, 6.6.z, 7, 7.1.eus and 7.2.eus.

Client with 5.9.z can move to 5 and from 5 to 5.9.z. When in "(none, disable service)" or in custom channel, only 5 is offered.

Client with 6.4.z can move to 6.6.z, then to 6, then to 6.6.z (but not from 6 to 6.4.z). When in "(none, disable service)" or in custom channel, only 6 is offered.

Client with 7.1.eus can move to 7.2.eus, then to 7 and then to 7.2.eus (but not from 7 to 7.1.eus). When in "(none, disable service)" or in custom channel, only 7 is offered.