Better handling of repositories coming from external sources

[ptoscano]

subscription-manager is the tool currently in use in RHEL to let users registers their systems. One of the functions it currently does is to fetch the list of repositories available for the current system, managing them on its own as /etc/yum.repos.d/redhat.repo. This is functionality is exposed to the user as separate subcommand:

# subscription-manager repos --help
usage: subscription-manager repos [OPTIONS]

List the repositories which this system is entitled to use

optional arguments:
  -h, --help            show this help message and exit
  --proxy PROXY_URL     proxy URL in the form of hostname:port
  --proxyuser PROXY_USER
                        user for HTTP proxy with basic authentication
  --proxypassword PROXY_PASSWORD
                        password for HTTP proxy with basic authentication
  --noproxy NO_PROXY    host suffixes that should bypass HTTP proxy
  --no-progress-messages
                        Do not display progress messages
  --list                list all known repositories for this system
  --list-enabled        list known, enabled repositories for this system
  --list-disabled       list known, disabled repositories for this system
  --enable REPOID       repository to enable (can be specified more than once). Wildcards (* and ?) are supported.
  --disable REPOID      repository to disable (can be specified more than once). Wildcards (* and ?) are supported.

Also, since the repositories come from the subscription server, subscription-manager has to store server-side additional metadata for each repository: because of that, it is not possible to manually edit redhat.repo (the changes are overwritten the next time subscription-manager or its dnf plugin run), and a separate way (implemented as subcommand) to handle these extra metadata is needed:

# subscription-manager repo-override --help
usage: subscription-manager repo-override [OPTIONS]

Manage custom content repository settings

optional arguments:
  -h, --help            show this help message and exit
  --proxy PROXY_URL     proxy URL in the form of hostname:port
  --proxyuser PROXY_USER
                        user for HTTP proxy with basic authentication
  --proxypassword PROXY_PASSWORD
                        password for HTTP proxy with basic authentication
  --noproxy NO_PROXY    host suffixes that should bypass HTTP proxy
  --no-progress-messages
                        Do not display progress messages
  --repo REPOID         repository to modify (can be specified more than once)
  --remove NAME         name of the override to remove (can be specified more than once); used with --repo option.
  --add NAME:VALUE      name and value of the option to override separated by a colon (can be specified more than once); used with --repo option.
  --remove-all          remove all overrides; can be specific to a repository by providing --repo
  --list                list all overrides; can be specific to a repository by providing --repo

While this approach "works", in practice it has a lot of drawbacks:

• subscription-manager needs to have a logic for reading/writing .repo files (dnf offers an help for this)
• redhat.repo is completely alien to dnf: dnf config-manager does not work with it, as the content comes from elsewhere
• subscription-manager is basically doing repository management on its own... which is exactly what dnf is for
• this duality of commands for managing the repositories you get via subscriptions is overly confusing for users, as they need to use the right commands depending on the "source" of the repositories

Hence, it would be nice if dnf had a clean way for external sources to integrate their own repositories with it using the plugin infrastructure. The request here is not to implement the logic of subscription-manager in dnf, of course, but rather something along the lines of:

• a plugin would be able to fetches repositories with metadata, and pass them back to dnf
• dnf would identify/associate those repositories for the plugin that provided them
• a plugin would be able to update the metadata of existing repositories it manages (and only those, perhaps, to avoid plugins stepping on each other toes)
• when dnf would want to change the metadata of a repository (e.g. via dnf config-manager), it would notify the plugin that "owns" that repository with the proposed metadata, so the plugin could be able to accept/reject them and do additional work

The only unsolved problem that I haven't been able to find a potential solution is the direct editing the .repo files.

Also, related to this is #405, recently created.

[jirihnidek]

The only unsolved problem that I haven't been able to find a potential solution is the direct editing the .repo files.

What about something like visudo? I mean not allow to edit redhat.repo directly in any text editor but allow to edit this file only in some "special editor" (e.g. we could call it repoedit). Users still could define their favorite editor using environment variablet EDITOR or VISUAL, but repoedit would:

• Locks the redhat.repo file
• Performs validity check
• Saves changes not only to redhat.repo, but it would also save changes to /var/lib/rhsm/cache/content_overrides.json and upload changes to candlepin server

[j-mracek]

There is a related bug - https://bugzilla.redhat.com/show_bug.cgi?id=2186015