ACK fix is upstream, one line fix:

https://github.com/theforeman/foreman_discovery/pull/441/files#diff-bca1f0e74fb3aabf3197a48e1c279c09R83

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Hmm, not quite sure why this bug is closed as "WONTFIX". Even though this has already been fixed in the upstream, I think this should be closed when the fix is released in the next release cycle.

Let me explain, it was a mis-click :-)

The patch was already merged upstream and released in 12.0.1 release (not announced yet tho).

Here is the fixed RPM package for you to try it:

http://koji.katello.org/koji/taskinfo?taskID=106909

Thanks, Lukas. I've instructed cus with a hotfix based on that one line change and it works like a charm.

Tested on Sat 6.4 Snap 20.

It seems that calling the "/api/v2/discovered_hosts/$id" endpoint still sets build mode to True. 

The hostgroup config:

# hammer hostgroup info --id 1
Id:                    1
Name:                  TestHostGroup
Title:                 TestHostGroup
Puppet Environment:    TestPuppetEnv
Description:           
  
Puppet CA Proxy:       satellite.example.com
Puppet Master Proxy:   satellite.example.com
Network:               
    Domain: example.com
Operating system:      
    Architecture:     x86_64
    Operating System: RHEL Server 7.5
    Partition Table:  Kickstart default
    PXE Loader:       PXELinux UEFI
Puppetclasses:         

Parameters:            

Locations:             
    Default Location
Organizations:         
    Default Organization
OpenSCAP Proxy:        
Content View:          
    ID:   1
    Name: Default Organization View
Lifecycle Environment: 
    ID:   1
    Name: Library
Content Source:        
    ID:   1
    Name: satellite.example.com
Kickstart Repository:  
    ID:   9
    Name: Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.5


I have discovered a virtual host using the FDI. The host was discovered with the ID 15.

Triggering provisioning using the API call. Notice the explicit '"build": "false"'

$ curl -X PUT -H 'Accept: application/json,version=2' -H 'Content-Type: application/json' -u admin:changeme -L -k -i 'https://satellite.example.com/api/v2/discovered_hosts/15' --data '{ 
"discovered_host": {
       "name": "client15",
       "hostgroup_id": 1,
       "build": "false"
        }
}'
HTTP/1.1 200 OK
Date: Wed, 05 Sep 2018 09:41:37 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Foreman_version: 1.18.0.18
Foreman_api_version: 2
Apipie-Checksum: bf5a9e3ec38f2bd61f26b75f6d1c39eecc6d9f43
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 3d4c50ea-6019-4f98-b012-fb0923a40b48
X-Runtime: 0.574297
Content-Security-Policy: default-src 'self'; child-src 'self'; connect-src 'self' ws: wss:; img-src 'self' data: *.gravatar.com; script-src 'unsafe-eval' 'unsafe-inline' 'self'; style-src 'unsafe-inline' 'self'
Strict-Transport-Security: max-age=631139040; includeSubdomains
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: sameorigin
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Powered-By: Phusion Passenger 4.0.18
Set-Cookie: request_method=PUT; path=/; secure; HttpOnly; SameSite=Lax
Set-Cookie: _session_id=d1a9f92eafa3b6511bdc71ffb21c41b4; path=/; secure; HttpOnly; SameSite=Lax
ETag: W/"6a992e9888d4d62eebf06dfe2b5ded15"
Status: 200 OK
Content-Length: 39
Content-Type: application/json; charset=utf-8


Check the host status: 

$ hammer host info --id 15 | grep Build
    Build:                  yes

At this point I have deleted the host, and rediscovered it again, this time with ID 16, and performed the provisioning using the hammer. Again, notice the explicit "--build false":

$ hammer discovery provision --id 16 --build false --hostgroup-id 1 --name client16
Host created
$ hammer host info --id 16 | grep Build
    Build:                  no

Using the API to provision a discovered host with the explict build false still switches the build mode on. Using hammer correctly sets the build mode to off.

Hey,

try to send it as a boolean:

{
	"discovered_host": {
		"name": "client15",
		"hostgroup_id": 1,
		"build": false
	}
}

Ok, enclosing the boolean in quotes was a mistake. With false this works as expected.


$ curl -X PUT -k -H 'Accept: application/json,version=2' -H 'Content-Type: application/json' -H 'Authorization: Basic YWRtaW46Y2hhbmdlbWU=' -i 'https://satellite.example.com/api/v2/discovered_hosts/25' --data '{
> "discovered_host": {
>        "name": "client25",
>        "hostgroup_id": 1,
>        "build": false
>         }
> }'
HTTP/1.1 200 OK
Date: Mon, 10 Sep 2018 07:52:13 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Foreman_version: 1.18.0.18
Foreman_api_version: 2
Apipie-Checksum: bf5a9e3ec38f2bd61f26b75f6d1c39eecc6d9f43
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: e7d16c81-7fbe-46a0-9df0-88cb4e1ed68e
X-Runtime: 0.559308
Content-Security-Policy: default-src 'self'; child-src 'self'; connect-src 'self' ws: wss:; img-src 'self' data: *.gravatar.com; script-src 'unsafe-eval' 'unsafe-inline' 'self'; style-src 'unsafe-inline' 'self'
Strict-Transport-Security: max-age=631139040; includeSubdomains
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: sameorigin
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Powered-By: Phusion Passenger 4.0.18
Set-Cookie: request_method=PUT; path=/; secure; HttpOnly; SameSite=Lax
Set-Cookie: _session_id=0af72ba62c83a1b521f339d6ad4c0008; path=/; secure; HttpOnly; SameSite=Lax
ETag: W/"f135046460569cc5148ae5bc67909906"
Status: 200 OK
Content-Length: 39
Content-Type: application/json; charset=utf-8

{"name":"client25.example.com","id":25}

$ hammer host info --id 25 | grep Build
    Build:                  no


Nevertheless, there is still a problem when using 0 instead of boolean, which should be supported according to API docs:

discovered_host[build]
optional , nil allowed 	

Validations:

Must be one of: true, false, 1, 0


$ curl -X PUT -k -H 'Accept: application/json,version=2' -H 'Content-Type: application/json' -H 'Authorization: Basic YWRtaW46Y2hhbmdlbWU=' -i 'https://satellite.example.com/api/v2/discovered_hosts/27' --data '{
> "discovered_host": {
>        "name": "client27",
>        "hostgroup_id": 1,
>        "build": 0
>         }
> }'

HTTP/1.1 200 OK
Date: Mon, 10 Sep 2018 08:01:58 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Foreman_version: 1.18.0.18
Foreman_api_version: 2
Apipie-Checksum: bf5a9e3ec38f2bd61f26b75f6d1c39eecc6d9f43
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 1a1807c9-6079-41ef-9c10-46d4cd1fdc93
X-Runtime: 0.309610
Content-Security-Policy: default-src 'self'; child-src 'self'; connect-src 'self' ws: wss:; img-src 'self' data: *.gravatar.com; script-src 'unsafe-eval' 'unsafe-inline' 'self'; style-src 'unsafe-inline' 'self'
Strict-Transport-Security: max-age=631139040; includeSubdomains
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: sameorigin
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Powered-By: Phusion Passenger 4.0.18
Set-Cookie: request_method=PUT; path=/; secure; HttpOnly; SameSite=Lax
Set-Cookie: _session_id=5413ae127d7ab0f52b9a2a7335225028; path=/; secure; HttpOnly; SameSite=Lax
ETag: W/"a2e350861bc48aeb562205cb965e9615"
Status: 200 OK
Content-Length: 39
Content-Type: application/json; charset=utf-8

{"name":"client27.example.com","id":27}

$ hammer host info --id 27 | grep Build
    Build:                  yes

I do believe this bug is VERIFIED and we need to discuss how we document boolean flags in our API. Integers must not be documented as supported, while they *can* work, they will definitely work at all places.

https://community.theforeman.org/t/boolean-normalization-in-the-api/11034

Let's revisit this bug next ween after the discussion is closed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2927