Project

General

Profile

Bug #21169

PUT on api/v2/operatingsystem/.../os_default_template/... is broken

Added by Matthias Dellweg almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

I tried to update the template to os association via APIv2 doing things like this (with different payloads)

$ curl -u admin:changeme -k https://centos7-devel/api/v2/operatingsystems/1/os_default_templates/2 -X PUT -H 'Content-Type: application/json' -d '{"id": 2, "provisioning_template_id": 97, "template_kind_id": 6, "operatingsystem_id": 1, "config_template_id": 97}'

and got this error:

{
"error": {"message":"Resource os_default_template not found by id '2'"}
}

I do not think, the "os_default_template" is what could not be found, because

$ curl -u admin:changeme -k https://centos7-devel/api/v2/operatingsystems/1/os_default_templates/2

got me this:

{"id":2,"provisioning_template_id":41,"provisioning_template_name":"Preseed default finish","template_kind_id":6,"template_kind_name":"finish","operatingsystem_id":1,"operatingsystem_name":"Debian stretch","config_template_id":41,"config_template_name":"Preseed default finish"}

Actually, i am trying to get this to work with nailgun, but i thought, the curl version is easier to debug.

History

#1 Updated by Matthias Dellweg almost 3 years ago

It seems, that the template_kind_id and provisioning_template_id should not be part of the first level dict in the payload.
If they are wrapped in to a os_default_template dict (as shown below) it works.
Maybe this was actually a nailgun error (see also: https://travis-ci.org/SatelliteQE/nailgun/jobs/283306637).

{"os_default_template": {"template_kind_id": 6, "provisioning_template_id": 97}} {"id": 2, "operatingsystem_id": 1, "os_default_template": {"template_kind_id": 6, "provisioning_template_id": 97}}

Having the provisioning_template_id directly in the params dict confuses foremans base_controller to deduce the right parent_class and results in an empty scope.

#3 Updated by Matthias Dellweg almost 3 years ago

Somehow this
https://bugzilla.redhat.com/show_bug.cgi?id=1151220
seems to be related.

Personally i do not think that this unwrapping of Params is a good thing anyway. And this particular problem shows, that it may fail in unpredictable ways. All in all it is not too complicated to wrap the Entity you want to change in a separate block of your json payload.

Also available in: Atom PDF