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.
But both of those options sound generally fine to me from the UX perspective. I probably lean towards option B. On Wed, Jan 22, 2020 at 10:26 AM Brian Bouterse <bmbou...@redhat.com> wrote: > FYI, this is for issue: https://pulp.plan.io/issues/5613 > > On Wed, Jan 22, 2020 at 10:24 AM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> 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. >> >> 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". >> >> # Option A: Compose the "repair" action endpoint under >> RepositoryVersionViewset >> >> 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. >> >> 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/. >> >> # Option B: Use a brand-new endpoint, e.g. /pulp/api/v3/repair/ >> >> 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. >> >> # Feedback: What do you think is best? >> >> Please reply to the list with what you think is best. >> >> [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. >> >> [0]: >> https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L181 >> >> Thanks! >> Brian >> >> _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev