<div dir="ltr"><div>Re: Option A, I'm not sure if my concern is warranted, but I'm a little wary of adding features to the RepositoryVersion endpoint because it already is special-cased in the bindings generator and it's kind of weird due to the nesting and the way it's sort-of generic but also exists under the plugins -- so I worry about making that situation more complex.<br></div><div><br></div><div>But both of those options sound generally fine to me from the UX perspective.  I probably lean towards option B.  <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 22, 2020 at 10:26 AM Brian Bouterse <<a href="mailto:bmbouter@redhat.com">bmbouter@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">FYI, this is for issue: <a href="https://pulp.plan.io/issues/5613" target="_blank">https://pulp.plan.io/issues/5613</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 22, 2020 at 10:24 AM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@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>A "repair" feature is being planned that will check-and-re-download all Artifacts associated with a RepositoryVersion. The last thing for us to work out is how the API will be offered to users.</div><div><br></div><div>Initially, the feature will launch to fix Artifacts for the 'latest' repository version for a given Repository, but over time it's likely we would want to support non-latest RepositoryVersion, or even "the whole Pulp system".</div><div><br></div><div># Option A: Compose the "repair" action endpoint under RepositoryVersionViewset</div><div><br></div><div>We could add an action endpoint to RepositoryVersionViewSet [0], which would provide /pulp/api/v3/repositories/rpm/rpm/<UUID>/repair/. Plugins could opt-out by overriding that endpoint to be a no-op which would also remove it from the bindings, so I think having an opt-out policy is safe.</div><div><br></div><div>Also since pulpcore analyzes+repairs Artifacts without plugin involvement, this will work for all plugins. This API natively works on any RepositoryVersion, which is nice. The one downside is that it if we add a "fix all of Pulp" feature later this composition approach won't work and we'd need to add a separate top-level API, like /pulp/api/v3/repair/.<br></div><div><br></div><div># Option B: Use a brand-new endpoint, e.g. /pulp/api/v3/repair/</div><div><br></div><div>Have it take repository_version or repository (and assume latest) as an argument and perform the repair on that. In the future the arguments could become optional, and this would provide the "repair all of Pulp" feature.</div><div><br></div><div># Feedback:  What do you think is best?</div><div><br></div><div>Please reply to the list with what you think is best.</div><div><br></div><div>[bmbouter's take] I am ok with either, but I have a preference for Option A because composition is a great user experience. Also we're not launching the global pulp checking feature right now anyway.</div><div><br></div><div>[0]: <a href="https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L181" target="_blank">https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L181</a></div><div><br></div><div>Thanks!</div><div>Brian</div><div><br></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>