<div dir="ltr">I had a similar idea in mind. How would this work with the sync_mode option though?<div><br></div><div>+1 to adding this to redmine.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, May 16, 2018 at 2:40 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I was thinking about these use cases. I'll use the same "first" and "second" that @dkliban described.</div><div><br></div><div>I recognize the "first" use case as a valid one. I think we could bring it to bear pretty easily with a little bit of plugin involvement. We could have a repository attribute boolen called exact_mirror (or similar) which when False would do the following:</div><div>(a) allow a plugin writer to implement the exact-saving of metadata as an Artifact</div><div>(b) disable add/remove of content using the always-raise an exception with this proposal here:  <a href="https://pulp.plan.io/issues/3541#note-3" target="_blank">https://pulp.plan.io/issues/35<wbr>41#note-3</a></div><div>(c) have the plugin API offer a generic publisher called NoMetdataPublisher that blindly publishes all Artifacts associated with a RepoVersion</div><div><br></div><div>This would cause the repo and its metadata to get published exactly, and prevent core from corrupting it by changing the other content since we can't also change the metadata.</div><div><br></div><div>For the "second" use case, I think you could fulfil it by making an exact mirror of the orignal publish so that it's only published once. This adds a nice mirroring capability to Pulp.</div><div><br></div><div>Should we move these plans into Redmine? What else do we need to know?<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 14, 2018 at 3:12 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, May 14, 2018 at 1:27 PM, Justin Sherrill <span dir="ltr"><<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>I think it kind depends in how pulp would do it.  Thinking of the
      yum example, all the information is there in an upstream yum repo
      for pulp to import the 'publication' as is.  If it can be done
      'naturally' with a yum repo, there wouldn't be anything special
      around pulp -> pulp, it'd just be  yum_repo -> pulp. 
      However we'd need a pulp dev to chime in here :)<span class="m_3373310542871713984m_6836657065778496209HOEnZb"><font color="#888888"><br>
    </font></span></p><span class="m_3373310542871713984m_6836657065778496209HOEnZb"><font color="#888888">
    <p></p></font></span></div></blockquote></span>This workflow is two use cases in Pulp 3:<br><br>   - "As a user, I can create a repository version that is an exact mirror of a remote."<br>   - "As a user, I can publish a repository version without generating metadata."<br><br>The first use case would be satisfied by having the plugin provide code that downloads the metadata from the remote and saves it as 'metadata content' that's part of the repository version. <br></div><div class="gmail_quote"><div><br></div><div>The second use case could be satisfied by pulpcore providing a generic publisher that pubilshes everything in a repository version. The metadata would just be treated like any other files in the repo. <br></div><div><div class="m_3373310542871713984h5"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="m_3373310542871713984m_6836657065778496209HOEnZb"><font color="#888888"><p>Justin<br>
    </p></font></span><div><div class="m_3373310542871713984m_6836657065778496209h5">
    <br>
    <div class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-cite-prefix">On 05/14/2018 12:08 PM, Bryan Kearney
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>@Justin, I think that makes sense for Pulp->Pulp. For Matthias, I think
he needs Native->Pulp which would not have a publication.

-- bk

On 05/14/2018 11:42 AM, Matthias Dellweg wrote:
</pre>
      <blockquote type="cite">
        <pre>Mirroring the metedata exactly is also very important for Debian
Repositories, because of the way the metadata is signed in lieu of the
whole content. So it would be very beneficial, if this could be
provided as a 'service' of the pulp core platform somehow.

Matthias

On Mon, 14 May 2018 11:31:52 -0400
Justin Sherrill <a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-rfc2396E" href="mailto:jsherril@redhat.com" target="_blank"><jsherril@redhat.com></a> wrote:

</pre>
        <blockquote type="cite">
          <pre> From my understanding of pulp 3, this would maybe involve the
ability to 'import' a publication.  Would that make sense?

Justin


On 05/09/2018 08:22 AM, Bryan Kearney wrote:
</pre>
          <blockquote type="cite">
            <pre>One of the themes I heard yesterday at the Red Hat Summit was around
having a pulp server mirror the upstream RPM repo metadata exactly.
The use case is that two pulp servers are behind a load balancer
mirroring the same repo. The users would like to be able to flip a
yum client acrross the two servers. Running createrepo to make
unique repos causes issues for the clients that appear to be
errors. I assume this pattern would not be unique for other package
clients that cache metadata.

So, when looking ahead to pulp 3 I would ask that this be taken into
consideration. I can provide more info / use cases if necessary.

-- bk



______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a>  
</pre>
          </blockquote>
          <pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a>
</pre>
        </blockquote>
      </blockquote>
      <pre></pre>
      <br>
      <fieldset class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_3373310542871713984m_6836657065778496209m_-8693516439752947101moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>______________________________<wbr>_________________<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<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<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<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div><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>