Katello 4.3 Cannot Republish Repository Metadata or View Packages of a Repository

Support
#1

Problem:
If I go to a repository page that doesn’t have any upstream source, I cannot republish repository metadata. If I click Select Action in top right corner, the only option I have available is “Remove Repository”. Also if I click on the number of Packages, previously I could view the packages in repository, instead now it is just a blank page and no packages listed. I tried creating a new repository, but it behaves the same way.

Expected outcome:
I should be able to republish repository metadata or view packages in the repo

Foreman and Proxy versions:
Katello 4.3 and Foreman 3.1

Distribution and version:
CentOS 7.9

Other relevant data:
Screenshot attached

image
image634×528 25.6 KB

#2

Hi @dgs,

Apologies, this is a known bug that we will be adding a fix for in an upcoming release (4.3.1).

In the meantime as a work-around, you can use the hammer CLI to
republish the repository

2 Likes
Cannot browse packages in yum repositories
#3

@Dewar I upgraded to Katello 4.3.1 today, but the button for me still looks the same, with only option being “Remove Repository” and no option to republish repository metadata.

But the upgrade did fix the other issue with blank page of packages - now I can click on the number of packages and view/search what is inside the repo.

#4

Hi @dgs

The bug Dewar linked relates only to the blank packages screen.

The removal of ‘republish repository metadata’ in the UI was intentional. The operation is pretty dangerous, especially if the repository uses Complete Mirroring, so it was decided to make the functionality less prominent.

If the repo is in a content view, you can still access this functionality via Hammer with

hammer content-view version republish-repositories

(add --help to the end to see all options)

Otherwise, for a single repository you can make a call to the API at /repositories/:id/republish with force: true. This is not yet added to Hammer; I’ve filed this issue to add it: Bug #34762: Add 'republish repository metadata' to Hammer - Katello - Foreman

1 Like
#5

Could you elaborate what makes this function dangerous? Are only repos with Complete Mirroring affected? What about deb repositories which do not have Complete mirroring ?

#6

Pulp folks will know more, but I think there is a risk of your metadata getting overwritten when that might not be desired. I don’t think repos without complete mirroring would be affected.

#7

Isn’t that the point? I want the metadata to be regenerated from scratch to fix some problem related to the metadata.

I end up running it on content view version with deb repositories, and it didn’t quite to that. Some missing folder structures appeared, but not all.

#8

Well, if you asked for a “complete mirror” then regenerating the metadata from scratch is not what you asked for. And that’s why the option to republish the metadata was hidden, because if you wanted perfect mirror then options which may undermine that could be bad.

With Mirror: Content Only or Additive, you should be able to regenerate the metadata at any time, no problem.

But I totally see how this wouldn’t be obvious from a UX perspective. There has been a lot of confusion around mirror modes in general so maybe a UX pass could be helpful? Maybe descriptions could be available on hover and options could be present in the menu but unavailable but with a description why?

(I’m not a UX person at all, I have no idea if that’s do-able with the current framework or even a good idea)

#9

I am probably misunderstanding what regenerating metadata does, please correct me if I am wrong.

I would expect for complete mirror/perfect mirror, where the metadata is I assume exactly the same - e.g. 1:1, for the data to verified that it is in fact 1:1. Thus potentially fixing any inconsistency.

I would expect from content only or additive for the metadata to again be verified by virtue of being regenerated based on what it is in the repo, thus fixing any inconsistency to what is being presented. For example, inconsistency that may have occurred after an update due to the pulp-deb generating slightly different metadata.

#10

I think this matches with what you’re saying but let me know if it doesn’t.

I would expect for complete mirror/perfect mirror, where the metadata is I assume exactly the same - e.g. 1:1, for the data to verified that it is in fact 1:1. Thus potentially fixing any inconsistency.

What happens is the metadata gets downloaded, checksums of the files are verified, and then the very same metadata files that were used during the sync get put into a publication at sync time. Instead of all the packages being moved to Packages/, they’re published in the same locations they are in the original repo. Also if the original metadata is signed, the signature remains intact.

I would expect from content only or additive for the metadata to again be verified by virtue of being regenerated based on what it is in the repo, thus fixing any inconsistency to what is being presented. For example, inconsistency that may have occurred after an update due to the pulp-deb generating slightly different metadata.

Pulp won’t produce exactly the same metadata, it should be functionally the same, but the packages might be listed in a different order, and the packages might be in different locations in the repo (ie. everything moved to Packages/) and as a result the checksums won’t be 100% identical and there’s no way to keep the original metadata signatures intact.

1 Like
#11

Complete mirror is an RPM only feature, so it makes no sense to hide the regenerate repository metadata button for deb content from fear that it is dangerous when used with rpm content using complete mirror.

Unfortunately I did not see this discussion earlier, but we need to find a way to stop making changes affecting all content types in order to work around a problem that only affects pulp_rpm’s “complete mirror” (which seems to require a lot of workarounds)…

#12

Update: It looks like the “republish repository metadata” feature will eventually come back once the potential for harm has been ironed out.

1 Like