Bug 1313676 - no way in webUI how to switch to EUS channel if you have mistakenly switched to main channel
no way in webUI how to switch to EUS channel if you have mistakenly switched ...
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI (Show other bugs)
570
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Grant Gainey
Red Hat Satellite QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-02 03:09 EST by Jan Hutař
Modified: 2016-03-03 02:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-03 02:59:25 EST
Type: Bug
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 Jan Hutař 2016-03-02 03:09:11 EST
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 06:29:11 EST
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 07:07:14 EST
Yeah, something definitely seems wrong here - I'll do some testing when I get in as well.
Comment 3 Tomas Lestach 2016-03-02 07:34:31 EST
Actually, this Comment#1 scenario works for me in upstream.
Comment 4 Jan Hutař 2016-03-02 13:52:40 EST
(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 15:01:01 EST
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 02:59:25 EST
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.

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