<div dir="ltr"><div>There is a video call scheduled to discuss this issue tomorrow (Tuesday April 28th) at 13:30 UTC (please convert to your local time).¬† <a href="https://meet.google.com/scy-csbx-qiu" target="_blank">https://meet.google.com/scy-csbx-qiu</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 25, 2020 at 7:02 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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"><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I had a chance to think about this some more yesterday and wanted to email out my thoughts. I also think that this change sounds scary and will have a big impact on plugin writers so I thought of a couple alternatives:</div><div><br></div><div>First, we could add a relative_path field to RepositoryContent instead of moving it there. This would be an optional field. It would be up to plugins to manage this field and they would still need to populate the relative_path field on ContentArtifact. But plugins could use this optional field to store relative paths per repository and then use this field when generating publications.</div><div><br></div><div>The second alternative is one that is already laid out in the original email but to call it out again: it would be to not solve this in pulpcore. RPM would create its own object that would map content in a repository to relative_paths.</div><div><br></div><div>David</div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 21, 2020 at 9:22 AM Quirin Pamp <<a href="mailto:pamp@atix.de" target="_blank">pamp@atix.de</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">
<div id="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin-top:0px;margin-bottom:0px">Hi,</p>
<p style="margin-top:0px;margin-bottom:0px"><br>
</p>
<p style="margin-top:0px;margin-bottom:0px">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:0px;margin-bottom:0px"><br>
</p>
<p style="margin-top:0px;margin-bottom:0px">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:0px;margin-bottom:0px"><br>
</p>
<p style="margin-top:0px;margin-bottom:0px">Thanks,</p>
<p style="margin-top:0px;margin-bottom:0px">Quirin Pamp<br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> <a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a> <<a href="mailto:pulp-dev-bounces@redhat.com" target="_blank">pulp-dev-bounces@redhat.com</a>> on behalf of Ina Panova <<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>><br>
<b>Sent:</b> 21 April 2020 14:07:13<br>
<b>To:</b> Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>><br>
<b>Cc:</b> Pulp-dev <<a href="mailto:pulp-dev@redhat.com" target="_blank">pulp-dev@redhat.com</a>><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">
<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>
<div dir="ltr">On Fri, Apr 17, 2020 at 5:57 PM Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>> wrote:<br>
</div>
<blockquote 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>
<div dir="ltr">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 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>
<div dir="ltr">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 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_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060x_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="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060x_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="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060x_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="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060x_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="gmail-m_-6286089361145814873gmail-m_4329576662106291799gmail-m_7275620558784531060x_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>
</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>
</blockquote></div>