Bug 1254617

Summary: [RFE] Provide a per custom repo metadata_expire configurable setting via UI and CLI
Product: Red Hat Satellite Reporter: Dave Sullivan <dsulliva>
Component: Content ManagementAssignee: Katello Bug Bin <katello-bugs>
Status: CLOSED MIGRATED QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: UnspecifiedCC: bkearney, mmccune, rdesouza, xdmoon
Target Milestone: UnspecifiedKeywords: FutureFeature, MigratedToJIRA, Reopened
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-05 21:23:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 260381    

Description Dave Sullivan 2015-08-18 13:56:18 UTC
Description of problem:

It's more convenient to handle this configuration in a single spot on the Sat6 Server side than to manage it from every client side per custom repo.
 
So the request here is to provide a configurable metadata_expire functionality administered from UI or CLI (hammer)


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

Sat 6.1.1



Additional info:

Mike McCunne mentioned it defaults to 1 and said that it currently not configurable.

While looking at this metadata_expire it might be worthwhile to look at any other options that yum provides as well.

Comment 1 Dave Sullivan 2015-08-18 14:01:40 UTC
This BZ sounds similar to this request

https://bugzilla.redhat.com/show_bug.cgi?id=1194714

Comment 3 Mike McCune 2015-09-17 14:56:52 UTC
Ensuring that we have a metadata expire at 1 ensures the systems always have the most current metadata and that updated content view publishes are *immediately* available to the end clients.

We are going to close this out as WONTFIX as the benefits of short expire times outweight custom, user editable expire times.

If there is a strong justification for this please feel free to re open.

Comment 4 Rafael Cardoso 2024-03-21 14:28:09 UTC
Hello,


According to the request of the case #03754873, and also considering the last modification of this RFE on 09/2015, I wonder if such feature could be added to the next Satellite releases.


Thanks in advance.

Comment 5 Eric Helms 2024-06-05 21:23:51 UTC
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.