Bug 1569310 - activation key keeps providing old repo path after repository change
Summary: activation key keeps providing old repo path after repository change
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Activation Keys
Version: 6.3.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1724792
TreeView+ depends on / blocked
 
Reported: 2018-04-19 03:30 UTC by Linqing Lu
Modified: 2019-06-28 16:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-22 14:22:16 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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