<div dir="ltr"><div dir="ltr"><div>I agree. +1. I revised the story to include the Publication attribute pass_through which is a Boolean and defaults to False, so the feature is disabled by default.</div><div><br></div><div>Sound ok?</div><div><a href="https://pulp.plan.io/issues/4020">https://pulp.plan.io/issues/4020</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 19, 2018 at 2:04 PM David Davis <<a href="mailto:daviddavis@redhat.com">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What about the case where a plugin publishes a subset of content from the repo version? Then the content app might match something it’s not supposed to.<div><br></div><div>I think @jortel mentioned having an option on the publication to pass through requests to the repo version if there’s no published artifact. That seems safer.<br clear="all"><div><div dir="ltr" class="m_3718599255225486888m_-8548549217169107281gmail_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></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 19, 2018 at 1:54 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you for all this feedback. I'm convinced that we should leave PublishedArtifact and PublishedMetadata as is w.r.t ticket #4020. I've revised it as such.</div><div><br></div><div>For the plugin writer I'm working with, they do want to have the ContentArtifact.relative_path be the final repository layout. So now the scope of work for #4020 is only to extend the content app to search ContentArtifact.relative_path before returning the 404 if no PublishedArtifact or PublishedMetadata objects match for that publication.</div><div><br></div><div>What about doing that? Also I'm kind of hoping to deliver this code to the plugin writer kind of soon. Thank you again for all the great input here and on the input.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 8:59 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think that pulp_deb could maybe create its own association between publication and artifacts. The problem is that PublishedArtifacts is a one-size-fits-all solution that probably ought to be instead implemented in plugins that require some specialized way to join publications and artifacts.<br clear="all"><div><div dir="ltr" class="m_3718599255225486888m_-8548549217169107281m_-7242606050971798400m_8819103259067430198gmail_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><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 4:51 AM Matthias Dellweg <<a href="mailto:dellweg@atix.de" target="_blank">dellweg@atix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not entierly sure, that this is related, but a while ago, we laid out a<br>
road map for the pulp3_deb plugin [1]. It includes 8 different<br>
publishers, that publish different metadata for the same repository<br>
version. As far as i understand, that is exactly, what<br>
PublishedArtifacts are for. If it were possible to just use ordinary<br>
Artifacts and associate them with a Publication instead of a<br>
RepositoryVersion it might be ok in that context.<br>
<br>
Cheers, Matthias<br>
<br>
[1] <a href="https://etherpad.net/p/pulp-deb-pulp3/timeslider#2902" rel="noreferrer" target="_blank">https://etherpad.net/p/pulp-deb-pulp3/timeslider#2902</a><br>
<br>
On Mon, 17 Sep 2018 12:45:15 -0400<br>
Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br>
<br>
> A plugin writer (@oleksander) pointed out to me that PublishedArtifact<br>
> seems a bit out of place for his usage. I can see why he thinks that,<br>
> and after thinking about it, Pulp does seem a bit over-complicated in<br>
> this area. I've written [0] to describe the problem, promote<br>
> discussion of this issue, and hopefully decide on a resolution.<br>
> <br>
> [0]: <a href="https://pulp.plan.io/issues/4020" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/4020</a><br>
> <br>
> Discussion and collaboration is welcome!<br>
> <br>
> -Brian<br>
_______________________________________________<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>
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>
</blockquote></div>