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
@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.
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
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 ?
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.
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)
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.
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.
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)…