Project

General

Profile

Actions

Bug #19313

closed

Auto-provisioning does not orchestrate TFTP

Added by Lukas Zapletal almost 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Urgent
Category:
Discovery plugin
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

When domain is blank, autoprovisioning fails for no apparent reason, logs are empty, something fails during orchestration and hosts are getting discovered again (which fails since managed host already exists).

Reproduced with Katello, user also reports similar behavior without Katello.

Bug in 1.14, high prio, regression.


Related issues 2 (0 open2 closed)

Related to Discovery - Bug #19409: Auto provision does not work after taxonomy fixClosedOhad Levy04/27/2017Actions
Related to Discovery - Bug #17873: foreman_url ignores templates proxy when provisioning discovered hostClosedTimo Goebel12/29/2016Actions
Actions #1

Updated by Lukas Zapletal almost 7 years ago

  • Description updated (diff)
Actions #2

Updated by Lukas Zapletal almost 7 years ago

  • Related to Bug #16982: CVE-2016-7078 - User with no organizations or locations can see all resources added
Actions #3

Updated by Lukas Zapletal almost 7 years ago

  • Related to Bug #19409: Auto provision does not work after taxonomy fix added
Actions #4

Updated by Lukas Zapletal almost 7 years ago

  • Status changed from New to Duplicate

Dupe of #19409

Actions #5

Updated by Lukas Zapletal almost 7 years ago

  • Related to deleted (Bug #16982: CVE-2016-7078 - User with no organizations or locations can see all resources)
Actions #6

Updated by Lukas Zapletal almost 7 years ago

  • Subject changed from Auto-provisioning fails with blank domain to Auto-provisioning does not orchestrate TFTP
  • Status changed from Duplicate to New
  • translation missing: en.field_release set to 241

Actually I don't think these are related. Still investigating.

Actions #7

Updated by Lukas Zapletal almost 7 years ago

  • Target version set to Discovery Plugin 9.1.0

This was found in 1.14 but setting it for 9.1 as well.

Actions #8

Updated by Lukas Zapletal almost 7 years ago

  • Subject changed from Auto-provisioning does not orchestrate TFTP to Auto-provisioning does not pick subnet/domain from hostgroup

Anyway, it looks like when subnet is not detected during discovery, auto-discovery does not pick up subnet/domain from hostgroup, therefore TFTP is not performed. Also this weird behavior happens when you try to Cancel Build, Edit or Build the host because Subnet is not actually set and it falls back to discovered name when you try to save it because FQDN is set in the primary NIC actually.

Actions #9

Updated by The Foreman Bot almost 7 years ago

  • Status changed from New to Ready For Testing
  • Assignee set to Lukas Zapletal
  • Pull request https://github.com/theforeman/foreman_discovery/pull/346 added
Actions #10

Updated by Lukas Zapletal almost 7 years ago

After discovered host is converted to Managed, associated NICs still have their associations set to the original record from the database (Host::Discovered), which led the host.managed? statement fail in tftp_ready? method in TFTP orchestration. This led to TFTP orchestration to be skipped completely, so I added a statement to set the appropriate assotiation explicitly during auto provisioning.

This is a regression and I cannot find the root cause of this, it worked previously. We have reports that both 1.14 and 1.15 are broken.

Actions #11

Updated by Lukas Zapletal almost 7 years ago

  • Subject changed from Auto-provisioning does not pick subnet/domain from hostgroup to Auto-provisioning does not orchestrate TFTP
Actions #12

Updated by Lukas Zapletal almost 7 years ago

  • Related to Bug #17873: foreman_url ignores templates proxy when provisioning discovered host added
Actions #13

Updated by Dominic Schlegel almost 7 years ago

I see the exact same behavior (no TFTP configs getting generated, no log/debug entries, reboot into FDI again) when provisioning a discovered host directly via API. The JSON i send to the API endpoint api/v2/discovered_hosts/:id looks like this:

{'discovered_host': {'operatingsystem_id': 3, 'root_pass': 'XXXXXX', 'managed': 1, 'ptable_id': 52, 
                     'medium_id': 4, 'subnet_id': 2, 'ip': '10.XXX.XXX.85', 'provision_method': 'build', 
                     'enabled': 1, 'hostgroup_id': 7, 'mac': 'XX:XX:XX:XX:XX:XX', 'architecture_id': 1, 
                     'build': 1, 'domain_id': 2, 'name': u'macXXXXXXXXXXXX'}
}

I found out that sending a request to api/hosts/:id/rebuild_config does finally generate the TFTP config. This indicates that something is wrong in the object conversion from Discovered Host to Managed Host. For the time being i am using this second API request as a workaround.

Actions #14

Updated by Anonymous almost 7 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF