Project

General

Profile

Actions

Bug #16686

open

issues when changing smart proxy settings while hosts are in build mode

Added by Marc 'Zugschlus' Haber about 8 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
TFTP
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Hi,

we are currently in the process of setting up PXE boot while the foreman installation is being used for a larger scale deployment issues. We have made the experience that foreman does not like it when subnet smart proxy settings are changed while hosts are set up for build. Edits to those hosts cannot be submitted until the subnet edit has been undone.

The error message is usually "unable to (set|delete) TFTP boot entry: 404 Resource not found". While, IMO, the tftp smart proxy is within its bounds to report that an entry that foreman wishes to delete or change is not there, foreman should handle this situation more gracefully.

Especially, it should be possible to delete a host even if its TFTP entry cannot be deleted.

While we're having this issue mainly with the TFTP smart proxy, I think this applies to the Smart Proxy interface in its entirety. I have had host edits bomb out because a DHCP subnet was doubled in the dhcpd configuration - a situation that the DHCP server itself handles gracefully, but foreman spewing errors in this case.

Greetings
Marc

Actions #1

Updated by Dominic Cleal about 8 years ago

  • Category set to TFTP

As a workaround you may change a host to unmanaged to prevent Foreman managing any of its TFTP or other orchestration actions on deletion, or to use the Rebuild Configs button to reinstate the missing file on the smart proxy server and then delete the host.

An override would perhaps be safest, as unknowingly ignoring errors removing TFTP files could result in the host booting incorrectly, even into an installer or other destructive process.

Actions #2

Updated by Marc 'Zugschlus' Haber about 8 years ago

As I wrote in the original report, the same issue will also apply to DHCP and other Smart Proxies.

If it will only be addressed in the tftp code, I'm fine with that (read as: I don't care). Just be prepared for a simliar bug report popping up for other smart proxies.

In the first place, the error message can be more clear and helpful. I appreciate you helping with workarounds, but those should either be in the docs, or given as hints in the error message, or not be necessary in the first place.

Greetings
Marc

Actions

Also available in: Atom PDF