| Summary: | [RFE] Allow content deliver to a system to be controlled by what subscription provides | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Og Maciel <omaciel> |
| Component: | Content Management | Assignee: | Katello Bug Bin <katello-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Katello QA List <katello-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.0.0 | CC: | bkearney |
| Target Milestone: | Unspecified | Keywords: | FutureFeature |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-09-08 18:49:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
I believe that Satellite 6.0 addresses this. If you disagree, please feel free to re-open the bug. |
Description of problem: After going through the lengthy process of uploading a manifest and specifically selecting the RHEL 6.2 RPMs repository, syncing it, promoting it to my product's Library -> Development environment, I was baffled as to why my RHEL 6.2 client could not use its content upon a successful subscription. When I ran yum repolist, the client always looked for a *6Server* repository in the SE, but sure enough, as that specific repository had not been synced or promoted, it received a 404. I talked to several people yesterday about this, and my point was that, if the system is to be managed by the SE and content delivery is controlled based on the subscription to which the system is associated, then my client should not be looking for the *6Server* but for the available *6.2* repository from the subscription. The issue here is that the client seems to dictate what repository can be used to deliver RHEL content, and not what the SEE provides it. This is basically what yum does: rpm -qf /etc/redhat-release --queryformat "%{VERSION}" Looking at my client now: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) # rpm -qf /etc/redhat-release redhat-release-server-6Server-6.2.0.3.el6.x86_64 # rpm -qi redhat-release-server-6Server-6.2.0.3.el6.x86_64 | grep Version Version : 6Server The proposed work around to make sure that my client tries to use the 6.2 repository are as follows, in no particular order: * call yum with --releasever 6.2 * search for and install for the 6.2 equivalent of redhat-release-server * select, sync and promote the 6Server repository alongside my 6.2 repository. I tried the last option, and sure enough it worked, but I strongly believe that if the process of controlling what goes into the client is controlled by the its subscription, then we should not be asking yum for further information, or at least the logic should not be in the client but in the SE. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: