Bug 1645749 - repositories controller responds with 200 instead of 201 to a POST request
Summary: repositories controller responds with 200 instead of 201 to a POST request
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: API - Content
Version: 6.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: 6.8.0
Assignee: Swetha Seelam
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-03 10:30 UTC by Roman Plevka
Modified: 2020-05-20 13:56 UTC (History)
4 users (show)

Fixed In Version: tfm-rubygem-katello-3.15.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 28219 Normal Closed repositories controller responds with 200 instead of 201 to a POST request 2020-05-20 12:28:33 UTC

Description Roman Plevka 2018-11-03 10:30:30 UTC
Description of problem:

aking HTTP POST request to https://sat.com/katello/api/v2/repositories with  data {"content_type": "yum", "url": "http://inecas.fedorapeople.org/fakerepos/zoo2/", "name": "yvsIKReFpc", "product_id": 1048}.

Received HTTP 200 response: {...}

Version-Release number of selected component (if applicable):
sat6.5.0


Actual results:
api returns 200 OK

Expected results:
API should return 201 Created

Comment 2 Brad Buckingham 2018-11-06 18:29:16 UTC
Roman, is this a change in behavior from 6.4?

Comment 3 Roman Plevka 2019-01-11 09:18:42 UTC
(In reply to Brad Buckingham from comment #2)
> Roman, is this a change in behavior from 6.4?

No, it is not as far as I remember. However, the behavior is inconsistent with POSTing to other endpoints. Also it made us to do workarounds in our automation. I'd like to have this sorted out finally, It should be a trivial fix.

Comment 4 Bryan Kearney 2019-11-04 14:34:13 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 5 Swetha Seelam 2019-11-12 14:17:40 UTC
Connecting redmine issue https://projects.theforeman.org/issues/28219 from this bug

Comment 6 Bryan Kearney 2019-11-12 15:02:06 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 7 Bryan Kearney 2019-11-12 15:02:08 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 8 Bryan Kearney 2019-11-12 17:02:09 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 9 Bryan Kearney 2019-11-12 17:02:11 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 10 Bryan Kearney 2019-11-12 19:02:06 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 11 Bryan Kearney 2019-11-12 19:02:08 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 12 Bryan Kearney 2019-11-12 21:02:08 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 13 Bryan Kearney 2019-11-12 21:02:10 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 14 Bryan Kearney 2019-11-12 23:02:04 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 15 Bryan Kearney 2019-11-12 23:02:05 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 16 Bryan Kearney 2019-11-13 01:02:05 UTC
Upstream bug assigned to sseelaml@redhat.com

Comment 17 Bryan Kearney 2019-11-13 01:02:06 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/28219 has been resolved.


Note You need to log in before you can comment on or make changes to this bug.