Bug #12089
closedUnable to Associate OS to Provisioning Templates via API
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.
Updated by Ryan Dyer about 9 years ago
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] }
Updated by Dominic Cleal about 9 years ago
- 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]
.
Updated by Tomáš Strachota about 9 years ago
- Status changed from New to Assigned
- Assignee set to Tomáš Strachota
Updated by Tomáš Strachota about 9 years ago
The issue got fixed in current develop by merging patch for #10988 which removes some hacks around ProvisioningTemplate rename:
https://github.com/theforeman/foreman/commit/c1755e070ee10ee026e0b3996378368369c4ca83#diff-fa8faf553918630d1afb4537fb180e90L1
I don't think we want that patch in the 1.9.3 branch. At the same time I don't think we want my fix in the develop as it has no effect there:
https://github.com/tstrachota/foreman/commit/63e2be4dfca70cfb17e4ce06fdc2f6291e6f94cc
What do you think, should I open a PR against the 1.9.3 stable branch?
Updated by Dominic Cleal about 9 years ago
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.
Updated by Tomáš Strachota about 9 years ago
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.
Updated by Dominic Cleal about 9 years ago
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.
Updated by The Foreman Bot about 9 years ago
- Status changed from Assigned to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/2851 added
- Pull request deleted (
)
Updated by Tomáš Strachota about 9 years ago
Updated by Anonymous about 9 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 7a3a1052eeddd984988f288b1b67a7a8adb7359e.