Bug 2184278 - Bring back the option to Republish Repository\CV Version metadata from Satellite UI
Summary: Bring back the option to Republish Repository\CV Version metadata from Satell...
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Repositories
Version: 6.12.0
Hardware: All
OS: Linux
Target Milestone: 6.14.0
Assignee: Jeremy Lenz
QA Contact: David Moore
: 2186276 2211489 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2023-04-04 05:59 UTC by Sayan Das
Modified: 2023-11-08 14:19 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2211964 (view as bug list)
Last Closed: 2023-11-08 14:19:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 36417 0 Normal Closed Bring back the option to Republish Repository\CV Version metadata in web UI 2023-06-02 14:45:42 UTC
Red Hat Issue Tracker SAT-17317 0 None None None 2023-05-18 14:47:09 UTC
Red Hat Product Errata RHSA-2023:6818 0 None None None 2023-11-08 14:19:27 UTC

Description Sayan Das 2023-04-04 05:59:37 UTC
Description of problem:

Before the release of Satellite 6.10, Satellite ( 6.9 and below ) GUI used to provide options to 

--> Republish individual Repository Metadata
--> Republish metadata for all repositories part of specific Content View versions.

These were helpful for the end-users as they don't need to remember commands or go back to CLI of the satellite to perform those tasks during specific troubleshooting being done. 

But now, This is no longer the case. 

* Satellite UI does not have the options anymore.

* hammer only provides an option for republishing metadata of content-view versions but not for the individual repositories enabled+synced.

* To perform the same action at the repository level, Users would always need to use the API `/katello/api/repositories/:ID/republish?force=true`

The fact that we still need to use the CLI methods for various reasons ( troubleshooting\hotfix application\bugfix ) etc., the missing options from UI is resulting in a negative user experience. 

Version-Release number of selected component (if applicable):

 - 6.10
 - 6.11
 - 6.12
 - 6.13

How reproducible:


Steps to Reproduce:

1. Install any of the said versions of satellite and enable + sync one repo

2. Create a CV and Publish it after adding the repo to it.

3. Explore the `Content --> Products` and `Content --> Content Views` pages to find out an option to Republish the repository metadata.

Actual results:

None found. 

Expected results:

Similar to 6.9, In current versions of satellite also, we should be able to republish repository metadata \ content-view version metadata from Satellite UI

Additional info:

I am not sure what to call this i.e. a BUG , an RFE or a Regression from the previous version ( 6.9 ) and hence i filed it as normal bug.

Comment 1 Sayan Das 2023-04-04 06:09:59 UTC
One of very good examples would be the fact that We need to refer to https://access.redhat.com/solutions/6663481 in the hotfix instructions for BZ https://bugzilla.redhat.com/show_bug.cgi?id=2103522#c39 

And there are many example BZs present for Sat 6.10 i believe where users are required to republish repository\content-view version metadata to fix\workaround certain bugs. 

So unless, There are some really obvious reasons + technical blockers, that why 

* We stopped providing the UI actions 
* We don't provide any hammer option to republish individual repository metadata

We should consider bringing those features back in future releases to deliver a positive customer experience.

Comment 2 Jeremy Lenz 2023-04-06 14:20:19 UTC
The UI actions were removed because regenerating repository metadata can be destructive if you use a certain mirroring policy, I believe.

In https://projects.theforeman.org/issues/34762 we added a `hammer repository republish` command to make things a bit easier.

We could think about adding the feature back to the UI, but it would have to take into account the dangers.

Comment 4 Sayan Das 2023-04-06 15:37:21 UTC
While the discussion makes sense, We are still only considering just the one mirroring policy here. 

There could be a number of situations where a repo metadata regeneration could be needed ( specifically the ones needing a hotfix to fix a few stuff and then republish the repodata ) and we need to rely on API or rake ( and in some cases hammer ).

The fact that we do provide the hammer way, should pose the same danger as the UI way since they are triggering the same action. So hiding\removing the option from UI is doing no good here if customers are anyway using the CLI options. 

It's simply my perspective but I will leave this to the dev-team .

I can see "hammer repository republish" in Satellite 6.12 , So that's much better than using the API.

Comment 5 Brad Buckingham 2023-04-12 17:43:49 UTC
*** Bug 2186276 has been marked as a duplicate of this bug. ***

Comment 6 Ian Ballou 2023-04-26 16:09:33 UTC
For this issue, I think the right approach would be to allow the republishing again from the UI, but disable it for "complete mirror" repositories because the metadata should be a 1:1 with the repository and hence a "regeneration" is unneeded. Plus, if the metadata is regenerated, the repository is no longer a complete mirror of the upstream.

Comment 8 Ian Ballou 2023-05-17 19:39:38 UTC
One tricky corner case that we discussed is the following: if a user has a non-filtered content view version with a repository that was "mirrored completely" and they change the library repository to no longer be mirrored, Katello will lose all track of whether or not that CVV repository was mirrored. At that point, we would have to assume that the CVV repo could have its publication regenerated. That would mean that old CVV repos would be changing from mirrored to "pulp generated".

I'm worried that users may regenerate the publication and then wonder why their old CVVs suddenly are behaving differently. Perhaps we could gate it with a "this could be dangerous, make sure you understand the consequences".

Knowing that this this will occur potentially to content view repositories, is this okay? Alternatively, if we're gating the feature with a warning, should we always allow them to regenerate publications even when they were mirrored?

Comment 9 Sayan Das 2023-05-18 06:00:57 UTC
While the suggestion makes sense and so as the other facts pointed out, I believe we are thinking in a bit wrong direction. 

It's not that what you are suggesting is not happening today. When it's needed or suggested by RedHat for something or googled for an RH KB to solve any package count issue, The end-users end up using hammer\API to perform metadata regeneration of content-view versions or repositories. 

So the problem you are pointing out is applicable even without having the GUI option present and that should not fall in the scope of this BZ. It should be a completely different RFE that includes the suggested WARNING in hammer\API\WebUI no matter who triggers that task.

All I had requested about this BZ was to bring back the UI option to do the metadata republish as that is far easier for an end-user to use instead of hammer\API.

Comment 10 Jeremy Lenz 2023-05-18 20:10:24 UTC
Created redmine issue https://projects.theforeman.org/issues/36417 from this bug

Comment 11 Jeremy Lenz 2023-05-18 21:16:04 UTC
> All I had requested about this BZ was to bring back the UI option to do the metadata republish as that is far easier for an end-user to use instead of hammer\API.

Okay. We decided we will bring it back to the API, but will disable it for repositories that use complete mirroring (you'll still have to use API/Hammer for that.)

Comment 12 Jeremy Lenz 2023-05-18 21:16:34 UTC
sorry, I meant bring it back to the Web UI

Comment 13 Jeremy Lenz 2023-05-19 12:59:23 UTC
Opened https://bugzilla.redhat.com/show_bug.cgi?id=2208535 as a followup

Comment 14 Ron Lavi 2023-06-01 14:07:28 UTC
*** Bug 2211489 has been marked as a duplicate of this bug. ***

Comment 15 David Moore 2023-07-11 20:17:31 UTC
Verified 6.14.0 snap 1

Republish Metadata for a single repository:
1. Create a product, sync one or more repos.
2. Navigate to the info page for an individual repo.
3. The 'Select Action' dropdown contains the option to 'Republish Repository Metadata'.

Republish Metadata for all repositories in a ContentView Version:
1. Create a product, sync two or more repos.
2. Create a content view, assign the synced repos, and publish a new version.
3. Navigate to the Versions tab of the ContentView.
4. Next to the 'Promote' button, the triple colon widget contains the option 'Republish Repository Metadata'.

Expected and actual results:
The republish task is started and completed without issue.
Only the repository or CV repositories used to initiate the action have their metadata republished.

Comment 18 errata-xmlrpc 2023-11-08 14:19:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.