Project

General

Profile

Actions

Bug #12516

closed

PUT request for discovered_hosts/[id] fails with "unknown attribute: nested"

Added by Yaniv Bronhaim over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Discovery plugin
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Request which used to work in Satellite 6.1 for provisioning new discovered host fails with the following error:

| Started PUT "/api/v2/discovered_hosts/mac525400452ffc" for 192.168.122.1 at 2015-11-12 04:30:01 -0500
2015-11-12 04:30:01 [app] [I] Processing by Api::V2::DiscoveredHostsController#update as JSON
2015-11-12 04:30:01 [app] [I] Parameters: {"discovered_host"=>{"name"=>"mac525400452ffc", "hostgroup_id"=>"1", "environment_id"=>"0", "mac"=>"52:54:00:45:2f:fc", "domain_id"=>"2", "subnet_
id"=>"1", "ip"=>"192.168.105.30", "architecture_id"=>"1", "operatingsystem_id"=>"1", "medium_id"=>"8", "ptable_id"=>"67", "root_pass"=>"[FILTERED]", "host_parameters_attributes"=>[{"name"=>"
host_ovirt_id", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"compute_resource_id", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"pass", "value"
=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"management", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}]}, "apiv"=>"v2", "id"=>"mac525400452ffc"}
2015-11-12 04:30:01 [app] [I] Authorized user admin(Admin User)
2015-11-12 04:30:02 [app] [W] Action failed | ActiveRecord::UnknownAttributeError: unknown attribute: nested | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_assignment.rb:88:in `block in assign_attributes' | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_assignment.rb:78:in `each' | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_assignment.rb:78:in `assign_attributes' | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/base.rb:498:in `initialize' | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/reflection.rb:183:in `new' | /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/reflection.rb:183:in `build_association'

After removing "nested" from all parameters in array I get: | | Started PUT "/api/v2/discovered_hosts/mac525400452ffc" for 192.168.122.1 at 2015-11-12 04:58:25 -0500
2015-11-12 04:58:27 [app] [I]


Related issues 1 (0 open1 closed)

Related to Foreman - Bug #12566: New Host API changed host_parameters_attributes behaviorClosedLukas Zapletal11/23/2015Actions
Actions #1

Updated by Lukas Zapletal over 8 years ago

  • Status changed from New to Need more information
  • Assignee set to Lukas Zapletal

Hello,

I see couple of "nested" options which are not expected. We support options as defined in http://theforeman.org/api/1.9/apidoc/v2/hosts.html#description-create

Remove those "nested" attributes.

Actions #2

Updated by Yaniv Bronhaim over 8 years ago

Lukas Zapletal wrote:

Hello,

I see couple of "nested" options which are not expected. We support options as defined in http://theforeman.org/api/1.9/apidoc/v2/hosts.html#description-create

Remove those "nested" attributes.

It was sent before (since ovirt 3.5) and it used to work with older versions of foreman\satellite.. I'd be glad if you could tell me since which version it started to throw the exception, because basically ovirt is broken when attaching foreman provider from this version and above

Actions #3

Updated by Yaniv Bronhaim over 8 years ago

Yaniv Bronhaim wrote:

Lukas Zapletal wrote:

Hello,

I see couple of "nested" options which are not expected. We support options as defined in http://theforeman.org/api/1.9/apidoc/v2/hosts.html#description-create

Remove those "nested" attributes.

It was sent before (since ovirt 3.5) and it used to work with older versions of foreman\satellite.. I'd be glad if you could tell me since which version it started to throw the exception, because basically ovirt is broken when attaching foreman provider from this version and above

When I say "it" I mean to the PUT request format

Actions #4

Updated by Lukas Zapletal over 8 years ago

I will try it out. How are you sending this API call? Via CLI? Via CURL? Is the JSON from our log accurate, or can you provide the original data you send?

Foreman version?

Actions #5

Updated by Yaniv Bronhaim over 8 years ago

All the answers appear in the issue description. we send rest api call to /api/v2/discovered_hosts/[id] -> the json format is as specified above: {"discovered_host"=>{"name"=>"mac525400452ffc", "hostgroup_id"=>"1", "environment_id"=>"0", "mac"=>"52:54:00:45:2f:fc", "domain_id"=>"2", "subnet_
id"=>"1", "ip"=>"192.168.105.30", "architecture_id"=>"1", "operatingsystem_id"=>"1", "medium_id"=>"8", "ptable_id"=>"67", "root_pass"=>"[FILTERED]", "host_parameters_attributes"=>[{"name"=>"
host_ovirt_id", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"compute_resource_id", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"pass", "value"
=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}, {"name"=>"management", "value"=>"[FILTERED]", "_destroy"=>"false", "nested"=>""}]}

Foreman 1.11 fails with it always. I'm trying to fetch log from where it used to work. iirc it was over satellite 6.1 few months ago

Actions #6

Updated by Dominic Cleal over 8 years ago

Those *_attributes are for the UI only which is why they've changed. They're not intended for use in the API, use the proper CRUD routes for adding parameters to hosts at /api/v2/hosts/:id/parameters.

Actions #7

Updated by Yaniv Bronhaim over 8 years ago

it means two separate api calls - after the provision is triggered and the host will get to /api/v2/hosts/:id (as before that the host appears only in /api/v2/discovered_hosts) - correct me if im wrong, you mean that the requests should be as follow:
- send api to provision /api/v2/discovered_host/:id
- check if host exists under /api/v2/hosts/:id
- add parameters to host /api/v2/hosts/:id (while its being provisioned)
?

Actions #8

Updated by Lukas Zapletal over 8 years ago

Yaniv,

can you please describe what you are trying to achieve? To me, it looks like you are trying to setup some oVirt options for discovered hosts. We don't support that, discovery is meant for bare-metal hosts. While you can use virtualization for them, the process of provisioning in Foreman is that we treat them like bare-metal.

If you need to setup something on them, please make a Feature request ticket and describe the requirement please. We can add the support in API V2 and priorize the work properly. If this was working before with UI controllers, there was some refactoring recently perhaps, as Dominic said.

Actions #9

Updated by Yaniv Bronhaim over 8 years ago

Pardon? I don't understand your question. This API call to trigger provision on discovered host used to work and now it fails

Actions #10

Updated by Lukas Zapletal over 8 years ago

Pardon? I don't understand your question. This API call to trigger provision on discovered host used to work and now it fails

Please pastebin me the JSON you send to foreman. The two provided examples are actually from the log, this won't work as its not a valid JSON (try with http://jsonlint.com).

I want to be sure I am testing with the same data as you are.

Actions #12

Updated by Lukas Zapletal over 8 years ago

Ok there were couple of changes in Foreman Core which changed behavior of this API. Discovery provisioning actually uses Foreman Core New Host call, except it adds few other things to the workflow.

commit 585329f5ef5980811b374a43dff57fc69c32e1c5
Author: Marek Hulan <mhulan@redhat.com>
Date:   Mon Sep 14 11:11:07 2015 +0200

    Fixes #11767 - avoid cleaning of interface attributes

commit 56309d5d74f228719baf486e3b6f2168037dbbd4
Author: Tom Caspy <tcaspy@gmail.com>
Date:   Thu Feb 5 16:43:15 2015 +0200

    fixes #9058 - interfaces should not be affected when changing loc/org

commit 4072434ca557b2cccb02daf3a17c9da4d59a9330
Author: Dominic Cleal <dcleal@redhat.com>
Date:   Fri Jun 26 13:42:42 2015 +0100

    Bump version to 1.10-develop

commit d4e53f27fefffc4a1b2b0f25f2d35accf5d4de6e
Author: Avi Tal <avi@primarydata.com>
Date:   Fri May 1 11:27:32 2015 +0300

    fixes #10342 - adding :host_parameters_attributes to except list in template_used()

Actions #13

Updated by Yaniv Bronhaim over 8 years ago

can you be more specific? Should those commits tell me something..? any workaround to make my call work with foreman 1.11? so I'll be able to test the flow with our current code.. any fix you can propose to have backward compatibility for that form of request?

Actions #14

Updated by Lukas Zapletal over 8 years ago

Ok I was able to create new host, I had to remove the nested attribute from there:

{
    "host": {
        "name": "test",
        "mac": "AA:BB:CC:DD:EE:F1",
        "organization_id": 3,
        "location_id": 2,
        "hostgroup_id": 7,
        "host_parameters_attributes": [
            {
                "name": "compute_resource_id",
                "value": "1",
                "_destroy": "false" 
            }
        ]
    }
}

The host_parameters_attributes is still supported in hosts API it looks like. Good, now I tried discovered host as well:

{
    "discovered_host": {
        "name": "mac525400130513",
        "organization_id": 3,
        "location_id": 2,
        "hostgroup_id": 7,
        "host_parameters_attributes": [
            {
                "name": "compute_resource_id",
                "value": "1",
                "_destroy": "false" 
            }
        ]
    }
}

TL;DR - remove the "nested" attributes, all of them.

Actions #15

Updated by Yaniv Bronhaim over 8 years ago

I did it already and got error 500, the request was sent and foreman ignored it.
can you tell exactly from which version this api is broken?

Actions #16

Updated by Lukas Zapletal over 8 years ago

  • Related to Bug #12566: New Host API changed host_parameters_attributes behavior added
Actions #17

Updated by Lukas Zapletal over 8 years ago

Reported the API breakage as #12566, we should not break the API like that.

Anyway, it works fine here. Show me the 500 log, I can't see anything.

Actions #18

Updated by Yaniv Bronhaim over 8 years ago

Without the "nested" it works as before. I fixed the issue in ovirt 3.6 side

Actions #19

Updated by Lukas Zapletal over 8 years ago

  • Status changed from Need more information to Closed

We have implemented a workaround in #12566 ticket - Foreman will no longer fail on "nested" attribute. There will be no Satellite 6 version affected by this, but Foreman 1.10 works this way, so please remove this from the codebase of oVirt. Thanks for report.

Actions #20

Updated by Qiong Wu about 8 years ago

What is the recommended way until Foreman 1.11 is released? I am facing this issue right now and need to use the affected feature, thanks!

Actions #21

Updated by Dominic Cleal about 8 years ago

Qiong Wu wrote:

What is the recommended way until Foreman 1.11 is released? I am facing this issue right now and need to use the affected feature, thanks!

The linked ticket is assigned to release 1.10.1, due next week (Foreman_110_Schedule).

Actions #22

Updated by Qiong Wu about 8 years ago

Thanks!

Actions

Also available in: Atom PDF