Project

Profile

Help

Network maintenance. Planio will be observing two scheduled maintenance windows this Tuesday, March 2 and Wednesday, March 3 from 02:00 UTC until 06:00 UTC each in order to perform maintenance on access routers in our primary datacenter. Your account might observe short downtimes during these periods up to several minutes at a time.

Story #7762

Need synchronous REST endpoint for (RPM) distribution update

Added by sskracic 4 months ago. Updated 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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