Project

Profile

Help

Story #7762

Need synchronous REST endpoint for (RPM) distribution update

Added by sskracic about 1 month ago. Updated 25 days ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

In a typical RHUI setup with 400+ repos and similar number of pending repository sync tasks, it would be of a great help to have ability to "publish" (ie. update their distribution with a publication that is already available) those repos that already have the latest metadata compiled without waiting for the sync task queue to drain. Alternatively, a way to "push" newly created distribution update onto the start of the task queue. In my understanding, updating a distribution looks like a lightweight task compared to sync or metadata generation tasks.

History

#1 Updated by bmbouter 25 days ago

We already have an endpoint that provides this just not synchronously. From a REST perspective how can we make the existing endpoint return a 200 in cases where the tasking system doesn't need to be involved, and a 202 where it does? My concern is that we're going to make two ways to do one thing? My other concern is that another API wouldn't be RESTful and would instead include some kind of verb since the noun resource, i.e. Distribution, is already using in this async API.

What do you all think our options are to have one viewset return different response types for different situations?

#2 Updated by daviddavis 25 days ago

I'm not quite sure I follow. You're proposing that the distribution update endpoint returns a 202 with a task or a 200 depending on what fields are being updated?

#3 Updated by bmbouter 25 days ago

daviddavis wrote:

I'm not quite sure I follow. You're proposing that the distribution update endpoint returns a 202 with a task or a 200 depending on what fields are being updated?

That's what I'm asking about yes.

#4 Updated by daviddavis 25 days ago

bmbouter wrote:

daviddavis wrote:

I'm not quite sure I follow. You're proposing that the distribution update endpoint returns a 202 with a task or a 200 depending on what fields are being updated?

That's what I'm asking about yes.

A couple thoughts off the top of my head: will the bindings handle different responses?

The other concern would be semantic versioning (ie if I update the publication field on a distribution today, I get back a 202 and task). I think we'll have to probably add a parameter or something to avoid breaking semver.

#5 Updated by bmbouter 25 days ago

daviddavis wrote:

A couple thoughts off the top of my head: will the bindings handle different responses? I don't know this is what stopped me as well. Webservers can respond with a lot of error codes, and I do see "reponses" listed in the browseable docs API, but I am not sure what openAPI provides for this.

The other concern would be semantic versioning (ie if I update the publication field on a distribution today, I get back a 202 and task). I think we'll have to probably add a parameter or something to avoid breaking semver.

I agree. It's a little strange admittedly but it still keeps one API endpoint which I think is important, and it's still RESTful.

Please register to edit this issue

Also available in: Atom PDF