-
Notifications
You must be signed in to change notification settings - Fork 39
Description
Currently, CAPT tells Smee to not allowing a machine to network boot after it has been provisioned. This happens by CAPT setting 2 values in a Hardware object. Hardware.Spec.Metadata.Instance.State
= provisioned
and Hardware.Spec.Metadata.State
= in_use
.
inUse = "in_use" |
provisioned = "provisioned" |
return hw.Spec.Metadata.State == inUse && hw.Spec.Metadata.Instance.State == provisioned |
if err := scope.patchHardwareStates(hw, inUse, provisioned); err != nil { |
hardware.Spec.Metadata.State = "" |
hardware.Spec.Metadata.Instance.State = "" |
This was the case because Smee was using these fields to gate network booting. This is no longer the case in Smee (since v0.10.0). Gating of network booting in Smee now occurs via Hardware.Spec.Interfaces[].Netboot.AllowPXE
.
The affect of this is that when a machine reboots, if the firmware is setup to network boot first, then the machine will be served network boot packets from Smee and the machine will boot into HookOS and sit there indefinitely.
Expected Behaviour
A machine provisioned by CAPT should not network boot after a reboot (hardware configured to tell Smee not to netboot a machine).
Current Behaviour
Possible Solution
Update CAPT to set Hardware.Spec.Interfaces[].Netboot.AllowPXE
= false
after a machine is provisioned.
Steps to Reproduce (for bugs)
- Provision a cluster with CAPT
- Set a machine's firmware to network boot
- Reboot the machine
- See that HookOS is loaded and sits indefinitely
Context
Your Environment
-
Operating System and version (e.g. Linux, Windows, MacOS):
-
How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
-
Link to your project or a code example to reproduce issue: