Description of problem: Currently, the Red Hat Repositories page offers all content provided by the Satellite's Manifest in a Cascading fashion where all available listings are listed on a per-product bases. For example, when expanding Red Hat Enterprise Linux Server, and then for RHEL 7, we get a list including the GA Minor releases and the base available full content: 7.0, 7.1, 7.2, 7.3, and then 7Server. People commonly misunderstand the purpose of the minor release repositories and then reason they exist, and how they can be properly used. There needs to be a common understanding that these repositories (minors) are dead from their moment of of the next minor's inception. They exist as a snapshot in time up to the GA of the next minor release. Once we move past a given minor release, there will never be updates, fixes, or security inclusions into those particular repositories. The only exception to this are the EUS Minor release repositories (In the situation of RHEL). These would need to be handled differently. The goal and initial proposal we are bringing for this is to make the following modifications: 1. For RHEL Minor release repositories (Non-EUS), we should list them under a different tab or category within the Repositories page (This could be listed as Unsupported/Limited Support, or even more simple as "Prior/Non-Current Releases"). This tab should provide a prominent note/warning of what to expect when using these repositories, and perhaps a link to the Satellite blog posts by Rich Jerrido explaining this content. 2. For RHEL Minor release respositories (EUS), we would need to find a different way to categorize. There will always be a few releases that are currently in support and therefore, we would not want to list them on a page where the assumption is that they are old/unsupported. There are a few ways to think about handling this. One that strikes me as a possibility would require buy-in from Candlepin. The simplest way to get information to every Satellite about what is currently supported and how it should be categorized in the Satellite WebUI/Repo page would be to include metadata within the Satellite manifest that could indicate EOL dates for repositories which can be referenced by Katello to manipulate how data is presented in regard to these items.
Is there a use case where a user would knowingly want a minor repository other than a EUS repo?
@Roxanne, Absolutely. We have many people that maintain minor releases of RHEL, even outside of EUS in an unsupported state. They don't understand that they are not supported, and in the end if there is a fix for their problem, we are just going to tell them to get errata from the next Minor Release or to not use a Minor and sync up to XServer. Unfortunately, this is a way of life for people that have applications or otherwise that dictate they must be using a certain Minor Release. As such, they have to be available, but we should direct people away from them unless they explicitly want them. It should also be explained in the place they are separated to that they are unsupported and may leave them exposed to various security and bug issues. Let me know if you have any other questions about this. Thanks.
A few thoughts: 1) I did do a new repository design (see attached). Feel free to set up time with me if you'd like me to walk you through it. As a note - it was designed prior to seeing this RFE. 2) I don't think creating a new tab or category would be consistent with the other categories present of which there are already seven. I would however think being able to differentiate our preferred repos in the UI through perhaps an icon and include a tooltip explaining the benefit of that repo might be a great option. Obviously this requires further discussion with dev to see what options are feasible.
Created attachment 1304073 [details] Repository Design
I would love to meet and review this. If we could get dev buy-in, differentiation of the unsupported repos that are part of a minor release which are not EUS could be determined by calculating: Highest available Minor Release - 1 = This minor and all below are unsupported. For EUS, it would be a bit more complex. I don't see a simple way to display what is supported within EUS without having some metadata for repositories that would be managed and delivered by RCM, which kind of comes back to another RFE we are trying to decide whether or not to act upon (Regarding showing the sizes of these repositories).
Craig, I've updated the design to include some of the features we talked about. Let me know if you have further feedback.
Created attachment 1314713 [details] Updated repo design
Roxanne, This looks great! Only looking for clarification on one piece: For the tool-tip on disabling a repo where you have described one as 'Orphaned', would this also be reflective of non-orphaned, but in-use repositories? (They would not be able to be disabled as they are published and in use somewhere, but are not orphaned content.)
From bug https://bugzilla.redhat.com/show_bug.cgi?id=1244286 I went back in forth looking at my manifest which should have provided a subscription to cover software collections but didn't see Software Collections under Content--->Red Hat Repositories--->RPMs Found out they were under the "Other" tab this is not very intuitive I would probably do the following: Change RPMs tab name to Core RPMs I'd move the "Other" tab to the right of "Core RPMs" tab and I would call it "Addon RPMs" On the "Core RPMs" tab page I would have a note at the top that mentions Addon RPMs, maybe a link" Note: See Addon RPMs tab for layered red hat repositories (e.g. Software Collections)
*** Bug 1455322 has been marked as a duplicate of this bug. ***
Connecting redmine issue http://projects.theforeman.org/issues/21151 from this bug
Upstream bug assigned to walden
*** Bug 1339755 has been marked as a duplicate of this bug. ***
This was resolved and no longer occuring SNAP 22. Feel free to send it back if so, but works fine on my SNAP 22 host.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2927