<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi,</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">I am not currently very well versed in the classes involved, but moving relative_path around sounds slightly scary with the potential to break things.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">As such, I would be interested to be kept in the loop as this moves forward. (Mailing list once there is some movement is entirely sufficient
<span>😉</span>)</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Thanks,</p>
<p style="margin-top:0;margin-bottom:0">Quirin Pamp<br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> pulp-dev-bounces@redhat.com <pulp-dev-bounces@redhat.com> on behalf of Ina Panova <ipanova@redhat.com><br>
<b>Sent:</b> 21 April 2020 14:07:13<br>
<b>To:</b> Daniel Alley <dalley@redhat.com><br>
<b>Cc:</b> Pulp-dev <pulp-dev@redhat.com><br>
<b>Subject:</b> Re: [Pulp-dev] the "relative path" problem</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Daniel,</div>
<div><br>
</div>
<div>how about setting up a meeting and brainstorm the alternatives, pros/cons there?<br>
</div>
<div>
<div>
<div dir="ltr" class="x_gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr"><br>
<br>
--------<br>
Regards,<br>
<br>
Ina Panova<br>
Senior Software Engineer| Pulp| Red Hat Inc.<br>
<br>
"Do not go where the path may lead,<br>
 go instead where there is no path and leave a trail."<br>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Fri, Apr 17, 2020 at 5:57 PM Daniel Alley <<a href="mailto:dalley@redhat.com">dalley@redhat.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">Bump, this item needs to move forwards soon.  Does anyone have any thoughts?<br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Wed, Apr 1, 2020 at 9:40 AM Pavel Picka <<a href="mailto:ppicka@redhat.com" target="_blank">ppicka@redhat.com</a>> wrote:<br>
</div>
<blockquote class="x_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="x_gmail_quote">
<div dir="ltr" class="x_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="x_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="x_gmail-m_-8146024664432765745gmail-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="x_gmail-m_-8146024664432765745gmail-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="x_gmail-m_-8146024664432765745gmail-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="x_gmail-m_-8146024664432765745gmail-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="x_gmail-m_-8146024664432765745gmail-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>
_______________________________________________<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>
</div>
</body>
</html>