<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 class="gmail_extra"><div class="gmail-m_429948599632220410h5"><div class="gmail_quote"><u>1. Core endpoints do not delegate/redirect to plugins.</u><br> - POST to /RepositoryVersion/ is removed.<br> - POST to /Publications/ (stays gone)<br> - Plugins provide endpoints for sync and other to create new
repository versions.<br> - Plugins provide endpoints for creating Publications
(publishing).<br></div></div></div></div></blockquote><div><br></div><div>I think this is a good characterization of what would change. I'd like to add my vision for why option 1 is optimal, leaving out my specific proposal.</div><div><br></div><div><ol><li><b>Plugins manage their own data.</b> All actions (sync/publish/add/remove/etc) are controlled by the plugin. Core provides tools to make this trivial in the trivial cases, but when a plugin needs to do something differently, core stays out of the way. This is the only pattern that makes sense when dealing with every possible plugin. We can't afford to make assumptions about what every plugin will and won't need.</li><li><b>Plugin writers follow a single pattern. </b>Create a model, a viewset, and a serializer. If the default behavior doesn't work for you, override it. The parts are modular, so you probably only need small changes. </li><li><b>Every action has a separate endpoint, and complete documentation. </b>If file/sync, file/add/, python/add, are all separate endpoints, they all have separate documentation. Each endpoint's also documents its parameters.</li></ol></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 class="gmail_extra"><div class="gmail-m_429948599632220410h5"><div class="gmail_quote"><br><u>2. Core delegates behavior to plugins for those endpoints
requiring plugin participation.</u><br> - POST to /RepositoryVersion/ is the only way to create a
repository version.<br> - POST to /Publications/ is the only way to create a
Publication (publish). <br> - The POST parameters or body includes enough information so
that core can select a plugin.<br> - Either the entire POST is passed along to the plugin, <u>or</u>
the plugin implements an API that's used by<br> core for pre-defined participation.<br></div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Restricting all repository version creation to a single endpoint is cool, but Option 2 means that pulpcore accepts requests that involve plugins. This begs the question, h</span>ow does core involve plugins? This is such an important question that it is difficult to discuss this idea at all outside of a specific implementation. </div><div><br></div><div>There is one thing that really bothers me about any possible implementation of Option 2, the documentation. If we combine various behaviors into a single endpoint, then how do we clearly document each of them?<br></div><div>The plan for Option 2 as I understand it would not document (in the docs) the specifics for how to sync/publish etc. Even if that problem is addressed somehow, we still have an awkward hierarchy. As you can see below, because plugins are primary in option 1, the action docs are separated by plugin. This makes sense, because each workflow involves only one plugin. </div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><ul><li>Option 1</li><ul><li>As a plugin x user</li><ul><li>I can sync.</li><li>I can add/remove</li></ul><li>As a plugin y user </li><ul><li>I can sync.</li><li>I can add/remove.</li></ul><li>As a plugin z user </li><ul><li>I can sync</li><li>I can add-complex-depsolving</li></ul></ul></ul></div><ul style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><li>Option 2</li><ul><li> As a user I can create a new RepositoryVersion</li><ul><li>by plugin x sync</li><li>by plugin x add/remove</li><li>by plugin y sync</li><li>by plugin y add/remove</li><li>by plugin z sync</li><li>by plugin z add-complex-depsolving</li></ul></ul></ul></div><div><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 class="gmail_extra"><div class="gmail-m_429948599632220410h5"><div class="gmail_quote">There have been proposals on how both #1 and #2 can be achieved. I'm </div></div></div></div></blockquote><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 class="gmail_extra"><div class="gmail-m_429948599632220410h5"><div class="gmail_quote">
wondering if we can even agree on one of these two approaches.<br></div></div></div></div></blockquote><div><br></div><div>It would be very convenient if we agreed on an approach separately from implementation, but I don't think it is possible. Each strategy has obvious pros but the cons are tucked away in the implementation details.</div><div> </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 class="gmail_extra"><div class="gmail-m_429948599632220410h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112HOEnZb"><div class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112h5"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112m_9074744428784529669h5">
<br>
<blockquote type="cite">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>A File repository version cannot be
properly published if it contains 2
FileContent units that both have the same
relative path. The publisher has to decide
which FileContent to publish at the relative
path. That decision cannot be made
intelligently by the publisher. The decision
on which content unit to include in the
repository version rests with the user that
is creating the repository version. When a
user tries to create a repository version
with a FileContent that has the same
relative path as another FileContent that
was added previously, Pulp needs to inform
the user that there is a conflict (and not
create the repositiory version). This
validation can only be provided by the File
plugin. <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </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>
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<div dir="ltr">
<div>We would
like to get
feedback on
these issues
being sound
and worth
resolving
before we
resume
particular
solution
discussion[1].</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Austin,
Dennis, and
Milan</div>
<div><br>
</div>
<div>[1] <a href="https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html" target="_blank">https://www.redhat.com/archive<wbr>s/pulp-dev/2018-March/msg00066<wbr>.html</a><br>
</div>
<div><br>
</div>
</div>
<br>
</span><span>______________________________<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>
</span></blockquote>
</div>
<br>
</div>
</div>
</div>
</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>
<br>
</div>
</div>
<br>
<fieldset class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112m_9074744428784529669m_-5698888641570368801m_-8082973026962369681m_2359146138886405596m_-6975650155196327159m_7479694530690954398m_8733354028057534058m_-4789151742247051920mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112m_9074744428784529669m_-5698888641570368801m_-8082973026962369681m_2359146138886405596m_-6975650155196327159m_7479694530690954398m_8733354028057534058m_-4789151742247051920moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="gmail-m_429948599632220410m_-1665596055420858361m_-4709153293767703112m_9074744428784529669m_-5698888641570368801m_-8082973026962369681m_2359146138886405596m_-6975650155196327159m_7479694530690954398m_8733354028057534058m_-4789151742247051920moz-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>
</span></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>
</blockquote>
<br>
</span></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>
</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><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><br><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><br></div></div>