Hide Forgot
Description of problem: operatingsystems_ids: [list_of_ids] has no effects in /architectures API endpoint and it looks there's actually a no way of associating OSes to arch via API: $ curl -sku admin:changeme https://sat63.com/api/v2/operatingsystems/1 | jq { "description": "RHEL Server 7.2", "major": "7", ...} $ curl -sku admin:changeme -X PUT -H 'content-type: application/json' -d '{"name": "rplevka_arch", "operatingsystem_ids": [1]}' https://sat63.com/api/v2/architectures/15 | jq { "created_at": "2016-11-25 12:45:58 UTC", "updated_at": "2016-11-25 12:45:58 UTC", "name": "rplevka_arch", "id": 15, "operatingsystems": [], "images": [] } $ curl -sku admin:changeme -X PUT -H 'content-type: application/json' -d '{"name": "rplevka_arch", "operatingsystem_ids": [1]}' https://sat63.com/api/v2/architectures/15 | jq { "created_at": "2016-11-25 12:45:58 UTC", "updated_at": "2016-11-25 12:45:58 UTC", "name": "rplevka_arch", "id": 15, "operatingsystems": [], "images": [] } Version-Release number of selected component (if applicable): satellite-6.3.0-6.1.beta.el7sat.noarch Actual results: operatingsystems not associated Expected results: operatingsystems associated
This seems to be a regression since as this works on the recent 6.2
I don't think this is a correct way of doing such call. Could you please let me know where you found it? This seems to work fine curl -X PUT -H 'content-type: application/json' -d '{"architecture": {"operatingsystem_ids": [1], "name": "i386"}}' https://admin:changeme@sat63.example.tst/api/v2/architectures/2 In Satellite 6.2 API documentation I see example with architectures using wrapped attributes. Also 6.2 live documentation at /apidoc/v2/architectures.html shows the wrapped variant. You're right it worked in 6.2 and no longer works in 6.3. It seems that there might be some issue with automatic wrapping which was the layer that should unify Katello and Foreman differences. The right solution would be unifying both APIs and introducing new version of API for that.
Thanks Marek, It only accepts the hash now. I've filed this BZ based on our automation results, which does not use the wrapping, so it looks like it relies on it. Could you investigate on the automatic wrapping? If it is by design, I would update our automation. thanks
I'm unable to find what changed this behavior, my guess would be something with strong params. Anyway I don't think we want to support this way. The example I provided in comment 3 should be used. There's an alternative to specify array of identifiers, e.g. curl -X PUT -H 'content-type: application/json' -d '{"operatingsystems": [{"name": "CentOS 6.7"}, {"id": 1}], "name": "i386"}' https://admin:changeme@sat63.example.tst/api/v2/architectures/2 but note that the key must be plural form of the resource (operatingsystems), not operatingsystem_ids. Both and id would work. Still, I'd recommend testing the documented way. I think we can close this BZ.
@mhulan, thanks for the explanation. based on the further discussion on irc i'm closing this and removing the test from our automation as no longer supported