It sounds like the issue is simply the discrepancy between the .repo file auto-generated by Pulp, and the .repo file generated by Satellite.  Functionally speaking the one Satellite creates is the one that Satellite uses, so the former is not a functional problem, only an artifact that leads to confusion - is that correct?

I believe Satellite 6.15 will resolve this, as the version of pulp_rpm present there has generation of the .repo file as an optional feature that defaults to false as opposed to an always-enabled one as it was previously.  I will need to double check that Satellite doesn't opt back in, however.

Confirmed that this ought to be resolved in 6.15, if my understanding of this issue is correct.

I'm not sure how to interpret the "to be resolved in 6.15" statement.

Does this imply that the GPG entries will be added or that the repo.config file will just not be generated?


In our use-case, content views are used to managed software updates.

Any repos not included in the content view are not available to the hosts.

The "published_at" path allows for these hosts to leverage the repo.config as a drop-in file to /etc/yum.repos.d/. The obvious workaround is to edit the contents with the gpgcheck and gpgkey values. It would seem that if this is already defined for the repo, then pulp should be using it.

Is there some other means to make the repo available without having to add it to the content view to which the host is currently assigned?

>I'm not sure how to interpret the "to be resolved in 6.15" statement.  Does this imply that the GPG entries will be added or that the repo.config file will just not be generated?

The latter.  Which is only a reasonable solution *if* the .repo file at the "published at" location is duplicative and isn't part of anyone's workflow, but it sounds like maybe it's part of yours?  Does it need to be?  Why avoid adding the repo to the host via Satellite?

>The obvious workaround is to edit the contents with the gpgcheck and gpgkey values. It would seem that if this is already defined for the repo, then pulp should be using it.

Satellite in this case knows more than Pulp does. Those values could probably be passed along, I'll need to talk with the Katello folks. 

But ideally since Satellite is already generating the .repo file, and since it has all the info available to it, we could just provide an easy way to copy that directly from the UI without even needing to go download it from "published at", if there's a compelling use case for that.

Would that be better than the current solution in your opinion?

>Is there some other means to make the repo available without having to add it to the content view to which the host is currently assigned?

I don't think so, currently?

From a Katello standpoint, we expect users to consume 'yum' content through subscription manager. The repo config that Pulp generates is something that Pulp happens to do that Katello doesn't take into account. When you use a content credential (gpg key) in Katello, we make sure it gets sent to Candlepin so that subscription-manager can add the gpg key to the repository files for you.

If there is interest in using Pulp's repo config file we could certainly consider it, but we'd need to see how it fits into our content consumption workflow. It would only work for custom/unprotected content though, since Candlepin and subscription-manager need to come into play to generate the entitlement certificates and stick them in the host's repository configuration.

Charles, can you expand a bit on your use case as discussed in comment #4?

* What is your use case for manually adding the repo rather than using Satellite to add the repo?
* If you need to do this, would you prefer some other means of accessing the auto-generated .repo file rather than visiting the "published at" location where it was previously published?

Hi Charles, I'm going to close this as per the discussion and the verification that the discrepancy no longer exists (by virtue of no separate config.repo existing), but we're open to accepting an RFE if there is a valid use case that isn't being met presently.

For our managed systems within our department, we utilize Puppet Enterprise.  Satellite is *not* the top our management chain, but merely a component. Our release cycle model also makes use of content-views.  As a host can only be associated with a single content-view, there is no way to use subscription-manager to add repos which exist outside the content-view.  When repository content which is not RH-managed is included in our content-views, problems have been encountered as the upstream content is not strictly managed.  Also, not all hosts will need access to all repositories, so having these included in the composite content-view complicates the release cycle and publishing. 

Here is a practical example. Only Oracle clients will have need for the Oracle Client repository.  Upstream, the URL for RHEL9 compatible packages is 

    https://yum.oracle.com/repo/OracleLinux/OL9/oracle/instantclient/x86_64/

Following the defined security model, documentation, approval, and eventually a proxy rule would be needed for this external access. Instead, Satellite is used as a mirror.  Adding this repo to a host simply requires:

    curl https://mysatellite/pulp/content/myorg/Library/custom/Oracle_Instant_Client/OL9_Instant_Client_19/config.repo > /etc/yum.repos.d/oracle9ic.repo

This is the exact use case that prompted this bug report. Pulp already has access to the package signing information and it should be able to be easily integrated into the generated `.repo` file.


We also have hosts utilizing Satellite for RH content what are not included in our model. There are multiple users across various campus departments which have been given activation keys to register their hosts. The management of these is beyond the scope of the service we provide. Having the pulp-managed `config.repo` makes it easy to offer access to the mirrored content without the need to involve changes to the activation key subscriptions and repository sets.

>Pulp already has access to the package signing information and it should be able to be easily integrated into the generated `.repo` file.

Well, Pulp doesn't have access to the package signing information (including public keys), just the repo metadata signing information. 

The overall use case does sound reasonable though.

Since Pulp doesn't have access to the signing keys, that means we would either need to have a hammer command to dump the .repo file, or we need to configure Pulp with all of extra information that Satellite has that Pulp doesn't have so that Pulp can reproduce the same .repo file.

The first approach seems generally useful, but I'm unsure if that is quite as convenient to do with your automation?  Is that enough or do you really need it to be downloadable directly from the repo URL itself?

@iballou, curious about your thoughts as well

One RFE I'll promote that has had some engineering design put into it is https://bugzilla.redhat.com/show_bug.cgi?id=1203267.

We are planning to eventually support having multiple content views & lifecycle environments for each host. If that interests you, feel free to leave a comment on the BZ to add yourself to the list of interested users.

---

Back to this RFE, if Katello only needs to start associating its repository GPG keys with a backend object in Pulp, I think the added complexity would be very low. We could also have a configurable option to generate the Pulp repo config files (although I suppose there's no harm in always having them generated if they actually work).

Daniel, I took a glance at the pulp-rpm API but I'm not sure which entity would store a GPG key.

I wasn't thinking so much that Katello would hand Pulp the keys to be hosted directly - it sounds like Katello is already hosting them, and could tell Pulp what URL to use to retrieve it.  The RpmRepository object type has a "repo_config" field which can be filled with key value pairs, which are passed into the repo.config generation.  I think Katello could probably hand it a URL.

I was thinking the same thing, Katello just needs to enter the GPG key location into the repo_config then.

I'm reopening this BZ then as an RFE since supporting the Pulp config file is essentially a new think for Satellite.

I'm not sure what other "needinfo" is waiting on me.  I keep getting reminders.  Is there something I'm missing?  
I see this was transferred to Jira, but I don't have access to those contents.

Am I missing something?

I had asked the question

> Since Pulp doesn't have access to the signing keys, that means we would either need to have a hammer command to dump the .repo file, or we need to configure Pulp with all of extra information that Satellite has that Pulp doesn't have so that Pulp can reproduce the same .repo file.

> The first approach seems generally useful, but I'm unsure if that is quite as convenient to do with your automation?  Is that enough or do you really need it to be downloadable directly from the repo URL itself?

Basically - would you need it to be downloadable from the repo URL itself to satisfy your automation needs, or would a hammer CLI command (or, I suppose Katello API call) be sufficient

> downloadable from the repo URL

This would be the most useful.  Making a hammer call or API call could be integrated, but it seems overkill for a very small file that's only going to update with changes to the repo.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.