Description of problem: According to apidoc we have only one possible parameter for `/api/v2/discovered_hosts/facts` - `facts`: `facts` - Hash containing facts for the host with minimum set of facts: discovery_bootif, macaddress_eth0, ipaddress, ipaddress_eth0, interfaces: eth0 (example in case primary interface is named eth0) Providing next list of values for facts: u'facts': { u'name': 'test', u'discovery_bootip': '10.8.118.28', u'discovery_bootif': '96:af:9d:19:17:89', u'interfaces': 'eth0', u'ipaddress': '10.8.118.28', u'macaddress': '96:af:9d:19:17:89', u'macaddress_eth0': '96:af:9d:19:17:89', u'ipaddress_eth0': '10.8.118.28', u'network_eth0': '10.8.118.0', u'link_eth0': 'true' } Getting next error: 'Validation failed: Subnet is not defined for host's location., Subnet is not defined for host's organization.' 1) Documentation doesn't mention that we need something more than minimal parameters 2) It doesn't seem that `facts` hash can receive any information about location, organization or subnets 3) We have only facts parameter, so it doesn't seem that we can send something more to the server 4) Even if I create new subnet entity and associate it with organizations and locations and then use that subnet address for my discovered host, it doesn't help either. Version-Release number of selected component (if applicable): 6.2 SNAP 17 (but it exists since BETA) How reproducible: Always Steps to Reproduce: 1. Try to create new discovered hosts using /facts address providing all required parameters 2. 3. Actual results: Getting error Expected results: Discovered hosts is created successfully Additional info:
Thanks for report. Valid 6.2.z bug, non critical. You need to create valid subnet that will match pxebooted interface assigning it org and loc you want to discover into. Might be doco only bug, need to investigate.
The problem is that on the host the set_taxonomy from facts is only done after the facts that set the interfaces is done. And in the set of the interfaces there is a check that validates that the host.location must be included in the subnet.location. This will ofcourse fail because the host.location is then still NULL. Swapping the set_taxonomy and other fact parsign will fix this. --- /usr/share/foreman/app/models/host/base.rb.160825-2 2016-08-25 14:15:43.286873877 +0000 +++ /usr/share/foreman/app/models/host/base.rb 2016-08-25 14:16:01.335925013 +0000 @@ -150,8 +150,8 @@ self.importing_facts = true save(:validate => false) - populate_fields_from_facts(facts, type) set_taxonomies(facts) + populate_fields_from_facts(facts, type) # we are saving here with no validations, as we want this process to be as fast # as possible, assuming we already have all the right settings in Foreman.
Thanks for analysis and the patch, I submitted it for review. http://projects.theforeman.org/issues/16449
Upstream bug component is Fact
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16449 has been resolved.
Verified in Satellite 6.3 snap 6 using robotello test (https://github.com/SatelliteQE/robottelo/blob/a8e4b3782a12adef2e175a54bb4edc00098ad85c/tests/foreman/api/test_discoveredhost.py#L132) Facts are uploaded correctly for discovered hosts, see the attached screenshot
Created attachment 1225236 [details] screenshot
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:0336
For the record, few months after the patch was merged a refactoring of puppet codebase reordered it back. I have noticed this and filed a fix with proper comment this should not be reversed anymore: https://projects.theforeman.org/issues/15409 However, I think the change does not have any impact on this particular bugzilla.