Bug #12089: Unable to Associate OS to Provisioning Templates via API - Foreman

Custom queries

3.11.5 release DONE
3.11.5 release TODO
3.12.2 release DONE
3.12.2 release TODO
3.13.0 release DONE
3.13.0 release TODO
All bugs by votes
All issues closed in the last 3 weeks
Easy and Trivial Issues
Easy Issues (only)
Foreman - new open issues in last 10 days
Good first issues - Foreman core
high prio open bugs
Host registration [open]
Mine
My issues closed in the last 3 weeks
old bugs
Open with target version set (aka blockers)
registration
taken-none
Team Atlas untriaged bugs
templates
Trivial Issues
Untriaged and opened in the past two weeks

Actions

Copy link

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

Assignee:

Tomáš Strachota

Category:

API

Target version:

1.9.3

Difficulty:

Triaged:

Bugzilla link:

Pull request:

https://github.com/theforeman/foreman/pull/2851

Fixed in Releases:

Found in Releases:

Red Hat JIRA:

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.

History
Notes
Property changes
Associated revisions

Actions

Copy link

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

Copy link

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

Copy link

Updated by Tomáš Strachota about 9 years ago

Status changed from New to Assigned
Assignee set to Tomáš Strachota

Actions

Copy link

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

Copy link

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

Copy link

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

Copy link

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

Copy link