Bug 1369310

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

If I register a freshly installed RHEL 6.8 beta system using subscription-manager, the default repository list does not contain the beta channel (rhel-6-server-beta-rpms).  As a result, installation of further packages results in difficult-to-diagnose yum errors, as can be seen in bug 1318525 comment 0.

The wrong repository list is a system misconfiguration, but subscription-manager could help users to avoid it.  Based on the experience with bug 1318525, it is quite difficult to recognize the root cause (it wasn't just me who was baffled by it).

--- Additional comment from John Sefler on 2016-03-22 16:23:54 CET ---

By design, the beta repos are included with your RHEL subscription.  They are simply disabled by default.  Unlike RHEL Server High Touch Beta (product ID 135), You do not need a special subscription to gain access to the beta repos, you just need the RHEL product cert installed.  Note...  the RHEL product cert and the RHEL Beta product cert are the same product (69 for variant Server).  They only differ cosmetically by the Version value.  I use the word cosmetically because subscription-manager does not use the Version value for making any decisions.  It's the product ID and tags that are used to determine what content is accessible.  Subscription-manager does not make any automatic decisions about what repos to enable (the defaults are chosen by release engineering).  The user can use "subscription-manager repos --help" to list and manually override the default repo enablement at any time thereby choosing to access the beta repos.

Note the following three product certs with versions 6.7, 6.8 Beta, and 6.7 Beta all have the same ID and tags and therefore are functionally identical to subscription-manager.

[root@jsefler-6 ~]# rct cat-cert /usr/share/rhsm/product/RHEL-6/Server-x86_64-d8fe2dce6654-69.pem | grep Product: -A8
Product:
	ID: 69
	Name: Red Hat Enterprise Linux Server
	Version: 6.7
	Arch: x86_64
	Tags: rhel-6,rhel-6-server
	Brand Type: 
	Brand Name: 

[root@jsefler-6 ~]# rct cat-cert /usr/share/rhsm/product/RHEL-6/Server-x86_64-fc525e82a324-69.pem | grep Product: -A8
Product:
	ID: 69
	Name: Red Hat Enterprise Linux Server
	Version: 6.8 Beta
	Arch: x86_64
	Tags: rhel-6,rhel-6-server
	Brand Type: 
	Brand Name: 

[root@jsefler-6 ~]# rct cat-cert /usr/share/rhsm/product/RHEL-6/Server-x86_64-ac748bf61722-69.pem | grep Product: -A8
Product:
	ID: 69
	Name: Red Hat Enterprise Linux Server
	Version: 6.7 Beta
	Arch: x86_64
	Tags: rhel-6,rhel-6-server
	Brand Type: 
	Brand Name: 

Having said all of this, I agree that the customer experience is misleading to see subscription-manager list --installed report "Version: 6.8 Beta" and the default enabled repos are the non-beta main stream rhel-6-server-rpms.  The rhel-6-server-beta-rpms are ALWAYS there (disabled by default).

--- Additional comment from Florian Weimer on 2016-03-23 10:23:15 CET ---

Thanks, John, for the explanation.

Could there be a low-tech solution to improve the situation?  Such as anaconda writing a channel list override to a magic file location, which is then used by subscription-manager to override the default channel selection coming from subscription management?  The KVM image we ship should contain this file as well.

--- Additional comment from John Sefler on 2016-03-23 14:55:47 CET ---

It feels like what you are asking for is a new behavior for auto-subscribe (which is technically a candlepin request).

Maybe it could work like this...
When autosubscribing for an installed product cert that is identified as a "beta" product cert in the cert's value for version, then candlepin will also search through the content sets of the auto-attached entitlement cert and create repo-overrides to enable all the repos that match a repo-id pattern like ".+-beta($|-.+)"  Would it also disable all other repos? I think not.

This idea is based on assumptions of how beta product certs and content are constructed.  I know the dev team would want a general solution.  I'm just brainstorming.

--- Additional comment from John Sefler on 2016-03-24 15:18:23 CET ---

As I jogged through my neighborhood last night, I liked this idea more and more...
Taking the liberty to turn this into an RFE.

Revising my brainstorm for how this works...
When the redhat.repo file is generated from the granted entitlement, I think there should be a routine that searches through the entitled content sets for repo-ids that match pattern ".+-beta($|-.+)".  When found, look at the required tags for the content set.  Find the installed product certs that provide these tags.  If any of these product certs have a Version field that contains the string "beta" (ignorecase), then create a repo-override on the consumer object to enable this beta repo.

I think this makes sense because if your system has a beta product cert installed, then the assumption is that your entitlement would give you access to the beta content without manual intervention to enable the beta repos.

The user could always use yum --enablerepo=BETA_REPO_1 or --disablerepo=BETA_REPO_2 to override the override.

Undecided if the user could use subscription-manager repo-override --remove to remove it.