Bug #21169
open
PUT on api/v2/operatingsystem/.../os_default_template/... is broken
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.
Updated by Matthias Dellweg over 6 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.
Updated by Matthias Dellweg over 6 years ago
Sorry, wrong link. I meant:
https://github.com/SatelliteQE/nailgun/pull/448
Updated by Matthias Dellweg over 6 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.