<div dir="ltr">This sounds great to me.<div><br></div><div>The one downside you cite is still an upside in my mind. There's been interest for some time in having the ability to do things such as:</div><div>- delete files on disk and convert to on-demand</div><div>- scan files on disk for corrupt ones and re-download them if found</div><div><br></div><div>Both of those cases would be well-supported by creating catalog entries for every file regardless of a repo's current download policy.</div><div><br></div><div>As you brought up, we will need to think about how large that table will become, but that seems like it should be manageable. I think the table would be on the same order of size (in terms of row count) as the association table, with the added dimension that multi-file units would have an entry for each file.</div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 1:09 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BACKGROUND:<br>
<br>
We have learned a lot about deferred (lazy) download catalog management in pulp2.  Currently, this is only<br>
supported by the RPM plugin importers.  The importer flow made adding support cumbersome. The importer(s) will<br>
generate catalog entries *only* when the download-policy is not "immediate" as follows:<br>
<br>
- For each unit not in the repository that it would have downloaded.<br>
- For each unit already associated.<br>
<br>
The reason for #2 is to support cases where the download policy has changed from "immediate" to one of the<br>
deferred policies.  After switching policies, the user has to do a sync to generate catalog entries.  The<br>
downside is the importer regenerates all of the entries when only a few are necessary.<br>
<br>
PROPOSAL:<br>
<br>
In pulp3, deferred download catalog management is provided by the proposed ChangeSet.  With this change in<br>
tooling, I want to propose a change in the strategy for managing catalog entries.  I propose the ChangeSet<br>
add/remove entries for content regardless of download-policy.<br>
<br>
This has the following advantages:<br>
<br>
- Changing download policies would not require a sync to generate catalog entries.<br>
<br>
- Better supports a use case we are starting to hear about.  "As a user, I want to reclaim disk space by<br>
switch to deferred download policy and then delete stored content."  Deleting stored content would be an<br>
entirely separate story.<br>
<br>
- The catalog could be managed by deltas but always be complete.  The overhead of managing the catalog is<br>
proportional to the number of units being added/removed from the repository.  That is, on initial sync, all<br>
the catalog entries are added.  Subsequent syncs will only add/remove entries for content being added/removed<br>
to the repository.<br>
<br>
- The downside is that users not using deferred downloading would incur the overhead of managing the catalog<br>
but we probably need benchmarks using postgres to evaluate this.<br>
<br>
<br>
Thoughts?<br>
<br>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>