Project

General

Profile

Actions

Bug #12089

closed

Unable to Associate OS to Provisioning Templates via API

Added by Ryan Dyer about 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
High
Category:
API
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

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.

Actions #1

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] }

Actions #2

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].

Actions #3

Updated by Tomáš Strachota about 9 years ago

  • Status changed from New to Assigned
  • Assignee set to Tomáš Strachota
Actions #4

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?

Actions #5

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.

Actions #6

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.

Actions #7

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.

Actions #8

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 ()
Actions #10

Updated by Anonymous about 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF