Bug #12089
closed
Unable to Associate OS to Provisioning Templates via API
Added by Ryan Dyer over 8 years ago.
Updated almost 6 years ago.
Description
this is in regards to this thread: https://groups.google.com/forum/#!topic/foreman-dev/6wOeQeuJX5o
I am unable to associate an OS to a provisioning template via the API. The GET of a config_template has an operatingsystems field (hash), but the PUT expects an operatingsystem_ids (array). When I PUT the os_ids array, it succeeds from a server response perspective, but there is no actual association that occurs. In 1.6 I achieved this using a PUT of operatingsystems as a hash. I do not know which release changed this behavior.
I have found this issue on foreman 1.9.0.
This issue can be worked around by embedding the os_ids inside a config_template hash. eg:
"config_template": { "operatingsystem_ids": [1, 2, 3] }
- translation missing: en.field_release set to 91
Appears to part of the config to provisioning templates renaming, as wrap parameters looks like it's copying it into the wrong hash.
A basic update shows this:
2015-10-08T08:28:51 [app] [I] Started PUT "/api/v2/config_templates/1" for 127.0.0.1 at 2015-10-08 08:28:51 +0100
2015-10-08T08:28:51 [app] [I] Processing by Api::V2::ConfigTemplatesController#update as JSON
2015-10-08T08:28:51 [app] [I] Parameters: {"test"=>"foo", "apiv"=>"v2", "id"=>"1", "provisioning_template"=>{}}
That provisioning_template hash should be config_template, since the update action checks params[:config_template].
- Status changed from New to Assigned
- Assignee set to Tomáš Strachota
I think your fix is still valid for develop, Tomas. Although we removed the ConfigTemplate constant (which affects internal use and plugins), the public API still exists because it's part of API v2 - so your fix should still work in develop.
Well, the fix will do no harm in develop but it also won't fix anything as it's already fixed there. Removal of the const_missing hack affected api behaviour too.
Oh yes, so it did, I didn't expect that! Then yep, send a PR against 1.9-stable and we'll take it there (tests won't run on Jenkins FYI). Once that's in, I think we should also commit the test to develop so we ensure it keeps working, even if the fix wasn't needed.
- Status changed from Assigned to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2851 added
- Pull request deleted (
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by Anonymous