Plugins » Discovery

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

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

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?

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

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.

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)
?

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.

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

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.

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/host/provider/foreman/ForemanHostProviderProxy.java#L337 - Directly to the request. let me know if you want me to copy it to jsonlint with dummy values

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()

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?

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.

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?

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.

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

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!

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

Thanks!