Bug 1398637

Summary: API: operatingsystems_ids options for architectures in PUT/POST does not work at all
Product: Red Hat Satellite Reporter: Roman Plevka <rplevka>
Component: APIAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED NOTABUG QA Contact: Roman Plevka <rplevka>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3.0CC: bbuckingham, jcallaha, mhulan, rplevka
Target Milestone: UnspecifiedKeywords: Regression, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-30 10:14:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Roman Plevka 2016-11-25 12:55:51 UTC 
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
Comment 2 Roman Plevka 2016-11-25 13:07:26 UTC 
This seems to be a regression since as this works on the recent 6.2
Comment 3 Marek Hulan 2016-11-28 11:42:46 UTC 
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.
Comment 5 Roman Plevka 2016-11-29 09:38:45 UTC 
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
Comment 6 Marek Hulan 2016-11-29 16:34:29 UTC 
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.
Comment 7 Roman Plevka 2016-11-30 10:14:30 UTC 
@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