Bug 1569310

Summary:	activation key keeps providing old repo path after repository change
Product:	Red Hat Satellite	Reporter:	Linqing Lu <lilu>
Component:	Activation Keys	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.3.1	CC:	lilu
Target Milestone:	Unspecified
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-22 14:22:16 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:
Bug Depends On:
Bug Blocks:	1724792

Description Linqing Lu 2018-04-19 03:30:40 UTC

Description of problem:
After a change of repository within the same product, existing activation key with that product associated is still providing old/removed repo path to newly registered hosts.
That makes yum unable to find new/updated repository and throws errors.

Version-Release number of selected component (if applicable):
6.3.1

How reproducible:
always

Steps to Reproduce:
1. Enable repo "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server", and sync up content
2. Create activation key "key1", add related subscription
3. Enable repo "Red Hat Enterprise Linux 7 Server RPMs x86_64 7.4", and disable previously enabled "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server" (because for some tests we need latest 7.4.z content, not 7.5) and sync up content
4. Create activation key "key2", add related subscription
5. Now if I register a host via "key1", it will still be pointing to the old RHEL7 repo instead of 7.4 repo, and ends up with a yum error since no related content.

Actual results:
only key2 works, key1 fails

Expected results:
both key1 and key2 works and provides content to updated content.

Additional info:
Both activation keys showed the same repository group name "Red Hat Enterprise Linux 7 Server (RPMs)" in ActivationKey/RepositorySet view. That's also difficult to tell which actual repository is attached since both aforementioned RHEL7 repos are in the same repo group.

Comment 2 Brad Buckingham 2018-04-20 17:18:42 UTC

Hi Linqing,

On the activation key, did you set a 'Release Version' prior to registering the client?

When wanting the client to use a specific release, this must be set (e.g. Release Version = 7.4); otherwise, the default behavior is to use 7Server.

Comment 3 Linqing Lu 2018-04-24 00:59:08 UTC

(In reply to Brad Buckingham from comment #2)
> Hi Linqing,
> 
> On the activation key, did you set a 'Release Version' prior to registering
> the client?
> 
> When wanting the client to use a specific release, this must be set (e.g.
> Release Version = 7.4); otherwise, the default behavior is to use 7Server.

Hi Brad,

"Release Version" there was left empty by default.

A couple of follow-up questions:
 - when "Release Version" is empty (or 7Server, shouldn't the activation key work with 7.4 repo (as it's part of 7Server series) as default behavior? Also, "Red Hat Enterprise Linux 7 Server (RPMs)" is listed in the "Repository Sets" view which suggests there is RHEL7 repo available.
 - If that content is supposed to be unavailable by design, should we remove "Red Hat Enterprise Linux 7 Server (RPMs)" from "Repository Sets" list to reflect that change?

Thanks!

Comment 4 Brad Buckingham 2018-06-22 14:22:16 UTC

Hi,

Thanks for the feedback.

When release version is not set, the 7.4 repo would not work.  e.g. 7Server is the default and is used when building out the repository path (e.g. /content/dist/rhel/server/7/$releasever/$basearch/os).

Regarding "Red Hat Enterprise Linux 7 Server (RPMs)" being listed in the 'Repository Sets', that text is because it is based upon the name of the set versus the specific release version.  This is the same text that is shown on the 'Red Hat Repositories' page and is derived from the manifest/cdn.

Both of the above are working as expected and designed; therefore, I am going to recommend closing this bugzilla.  If there are concerns please do re-open or possibly open a separate RFE detailing the workflow and behavior that is desired.