[Pulp-dev] API for repairing bitrot -- input requested

Daniel Alley dalley at redhat.com
Wed Jan 22 16:07:48 UTC 2020


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 <bmbouter at 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 <bmbouter at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200122/44b92aa4/attachment.htm>


More information about the Pulp-dev mailing list