Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
At this point we have several different modules which control subscription manager preferences. In the GUI we have them in one window. In the CLI, we have 3 main preference modules that are scattered throughout the primary and other modules sections in help. In an effort to cut down on the number of modules we have (we've got more than 20 already), and make it easier to find what they're looking for without skimming through 20+ modules and their descriptions, we might be able to cut out our current preference/settings modules and move them into their own preferences module. That way when we have to add more preferences in the future (which I imagine we will at some point), we don't have to create an additional module for each one.
Might be able to put config in there as well, and a proxy module if we ever pull it out of all the other modules and give it its own home.
Here's what we currently have for modules:
Usage: subscription-manager MODULE-NAME [MODULE-OPTIONS] [--help]
Primary Modules:
attach Attach a specified subscription to the registered system
list List subscription and product information for this system
refresh Pull the latest subscription data from the server
register Register this system to the Customer Portal or another subscription management service
release Configure which operating system release to use [PREFERENCE]
remove Remove all or specific subscriptions from this system
status Show status information for this system's subscriptions and products
unregister Unregister this system from the Customer Portal or another subscription management service
Other Modules:
auto-attach Set if subscriptions are attached on a schedule (default of daily) [PREFERENCE]
clean Remove all local system and subscription data without affecting the server
config List, set, or remove the configuration parameters in use by this system
environments Display the environments available for a user
facts View or update the detected system information
identity Display the identity certificate for this system or request a new one
import Import certificates which were provided outside of the tool
orgs Display the organizations against which a user can register a system
repo-override Manage custom content repository settings
plugins View and configure subscription-manager plugins
redeem Attempt to redeem a subscription for a preconfigured system
repos List the repositories which this system is entitled to use
service-level Manage service levels for this system [PREFERENCE]
subscribe Deprecated, see attach
unsubscribe Deprecated, see remove
version Print version information
Additional info:
If it isn't possible to have modules in modules, maybe we should at least consider adding in a Preference Modules: section and listing them together, instead of scattering them across Primary and Other.
This seems like a good idea, however in the past we have avoided making similar changes because they might break scripts. If we leave legacy modules, we're compounding the problem.
Thoughts?
Description of problem: At this point we have several different modules which control subscription manager preferences. In the GUI we have them in one window. In the CLI, we have 3 main preference modules that are scattered throughout the primary and other modules sections in help. In an effort to cut down on the number of modules we have (we've got more than 20 already), and make it easier to find what they're looking for without skimming through 20+ modules and their descriptions, we might be able to cut out our current preference/settings modules and move them into their own preferences module. That way when we have to add more preferences in the future (which I imagine we will at some point), we don't have to create an additional module for each one. Might be able to put config in there as well, and a proxy module if we ever pull it out of all the other modules and give it its own home. Here's what we currently have for modules: Usage: subscription-manager MODULE-NAME [MODULE-OPTIONS] [--help] Primary Modules: attach Attach a specified subscription to the registered system list List subscription and product information for this system refresh Pull the latest subscription data from the server register Register this system to the Customer Portal or another subscription management service release Configure which operating system release to use [PREFERENCE] remove Remove all or specific subscriptions from this system status Show status information for this system's subscriptions and products unregister Unregister this system from the Customer Portal or another subscription management service Other Modules: auto-attach Set if subscriptions are attached on a schedule (default of daily) [PREFERENCE] clean Remove all local system and subscription data without affecting the server config List, set, or remove the configuration parameters in use by this system environments Display the environments available for a user facts View or update the detected system information identity Display the identity certificate for this system or request a new one import Import certificates which were provided outside of the tool orgs Display the organizations against which a user can register a system repo-override Manage custom content repository settings plugins View and configure subscription-manager plugins redeem Attempt to redeem a subscription for a preconfigured system repos List the repositories which this system is entitled to use service-level Manage service levels for this system [PREFERENCE] subscribe Deprecated, see attach unsubscribe Deprecated, see remove version Print version information Additional info: If it isn't possible to have modules in modules, maybe we should at least consider adding in a Preference Modules: section and listing them together, instead of scattering them across Primary and Other.