<div dir="ltr">Bump, this item needs to move forwards soon.  Does anyone have any thoughts?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 9:40 AM Pavel Picka <<a href="mailto:ppicka@redhat.com">ppicka@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi, <div>I'd like to add one more question to this topic. Do you think it is a blocker for PRs [0] & [1] as by testing [2] this features I haven't run into real world example where two really same name packages appears. </div><div>I think this is a 'must have' feature but until we solve/decide it we can have two features working may with warning in docs for users that can happen in some 'special' repositories. </div><div><br></div><div>To follow topic directly I like proposed move to 'RepositoryContent' and add it to its uniqueness constraint (if I understand well).</div><div><br></div><div>[0] <a href="https://github.com/pulp/pulp_rpm/pull/1657" target="_blank">https://github.com/pulp/pulp_rpm/pull/1657</a></div><div>[1] <a href="https://github.com/pulp/pulp_rpm/pull/1642" target="_blank">https://github.com/pulp/pulp_rpm/pull/1642</a></div><div>[2] tested with centos 7, 8, opensuse and SLE repositories</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 3:22 PM Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><h3 id="gmail-m_-8995103163427396541gmail-m_870933347578052004gmail-Problem"><font size="2"><span style="font-weight:normal">We'd like to start a discussion on the "relative path problem" identified recently.</span></font><br></h3><h3 id="gmail-m_-8995103163427396541gmail-m_870933347578052004gmail-Problem">Problem:</h3><p>Currently,
 a relative_path is tied to content in Pulp. This means that if a 
content unit exists in two places within a repository or across 
repositories, it has to be stored as two separate content units. This 
creates redundant data and potential confusion for users.</p><p>As a specific example, we need <a href="https://pulp.plan.io/issues/6353" rel="noopener" target="_blank">to support mirroring content in pulp_rpm</a>.
 Currently, for each location at which a single package is stored, we’ll
 need to create a content unit. We could end up with several records 
representing a single package. Users may be confused about why they see 
multiple records for a package and they may have trouble for example 
deciding which content unit to copy.</p><h3 id="gmail-m_-8995103163427396541gmail-m_870933347578052004gmail-Proposed-Solution">Proposed Solution:</h3><p>Move
 “relative_path” from its current location on ContentArtifact, to 
RepositoryContent. This will require a sizable data migration. It is 
possibly the case that in rare cases, repository versions may change 
slightly due to deduplication.</p><p>A
 repository-version-wide uniqueness constraint will be present on 
“relative_path”, independently of any other repository uniquness 
constraints (repo_key_fields) defined by the plugin writer.</p><p>Modify
 the Stages API so that the relative_path can be processed in the 
correct location – instead of “DeclarativeArtifact” it will likely need 
to go on “DeclarativeContent”</p><p>Remove
 “location_href” from the RPM Package content model – it was never a 
true part of the RPM (file) metadata, it is derived from the repository 
metadata. So storing it as a part of the Content unit doesn’t entirely 
make sense.</p><h3 id="gmail-m_-8995103163427396541gmail-m_870933347578052004gmail-Alternatives">Alternatives</h3><p>In
 most cases, a content unit will have a single relative path for a 
content unit. Creating a general solution to solve a one-off problem is 
usually not a good idea. As an alternative, we could look at another 
solution for mirroring content. One example might be to create a new 
object (e.g. RpmRepoMirrorContentMapping) that maps content to specific 
paths within a repo or repo version.</p><h3 id="gmail-m_-8995103163427396541gmail-m_870933347578052004gmail-Questions">Questions</h3><ul><li>How do we handle this in pulp_file? How are content units identified in pulp_file without relative_path?</li><ul><li>Checksum?<br></li></ul><li>How was this problem handled in Pulp 2?</li></ul><div><br></div><div>Please weigh in if you have any input on potential problems with the proposal, potential alternate solutions, or other insights or questions!<br></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Pavel Picka</div><div>Red Hat<br></div></div></div>
</blockquote></div>