| Summary: | No option to change preserve metadata in repo update | ||
|---|---|---|---|
| Product: | [Retired] Pulp | Reporter: | James Slagle <jslagle> |
| Component: | user-experience | Assignee: | Todd Sanders <tsanders> |
| Status: | CLOSED NOTABUG | QA Contact: | Preethi Thomas <pthomas> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | mhrivnak, rbowlby83, tsanders |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-09-27 14:18:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
James Slagle
2012-02-13 23:31:04 UTC
I think this was intentional to not accidentally override a mirrored repo. A user can clone a preserved repo and add custom content to it. This is particularly applicable to say Red Hat content and we dont want user to muck with the metadata. I'm open to discussion on if we want this to be optional. But seems to make sense to me to lock the repo if its treated as a mirror at the creation time. Supporting that case is what I had in mind, but it's not possible. You create a repo you intend to be mirrored and use --preserve-metadata. Clone that repo. You can't change the cloned repo to not be --preserve-metadata, b/c there is no such option in pulp-admin repo update. It's possible I'm not understanding the full behavior of --preserve-metadata. I was always under the impression that a cloned repo would not inherit the preserve_metadata flag. We already preserve the metadata(an in copy) when a repo is cloned. But once thats done, a clone repo should be open as in i should be able to upload content like any custom repo. If thats not happening, then i would think thats where the bug is. My concern here is, the only way to lock a repo today is with this preserve_metadata flag. If we allow an update, then we're giving the user opportunity to mess with their preserved content( red hat content) for example. The only way to fix bug: 782490 was for me to enable --preserve_metadata on the epel repo. Alas, I'd like to go back and modify all local repo mirrors of external content to preserve metadata. There's no way to do so as far as I can tell. We should be able to at least enable preserve_metadata on an existing repo whose feed is not local. the --preserve-metadata option no longer exists. |