I suppose the conversation we need is:

• Where will this live?
• What information will be sent, exactly?
• Where will the information be stored?
  • Netbox?
  • Puppet?

In T219908#5083435, @crusnov wrote:

I suppose the conversation we need is:

• Where will this live?

The install servers seems a good option IMHO

• What information will be sent, exactly?

See iPXE documentation, the API will be called like https://ipxe.org/scripting#dynamic_scripts and it should return the boot options for the appropriate d-i image, see also https://ipxe.org/scripting

• Where will the information be stored?
  • Netbox?
  • Puppet?

Which information are you referring to?
This API should need a storage, just a short-lived in memory cache and it should be writable by the cumin hosts (e.g. the reimage cookbook). It will connect to Netbox in RO mode and gather the FQDN of the host from the Serial Number and then resolve it's addresses via DNS.

In T219908#5084501, @Volans wrote:

In T219908#5083435, @crusnov wrote:

I suppose the conversation we need is:

• Where will this live?

The install servers seems a good option IMHO

• What information will be sent, exactly?

See iPXE documentation, the API will be called like https://ipxe.org/scripting#dynamic_scripts and it should return the boot options for the appropriate d-i image, see also https://ipxe.org/scripting

• Where will the information be stored?
  • Netbox?
  • Puppet?

Which information are you referring to?
This API should need a storage, just a short-lived in memory cache and it should be writable by the cumin hosts (e.g. the reimage cookbook). It will connect to Netbox in RO mode and gather the FQDN of the host from the Serial Number and then resolve it's addresses via DNS.

Okay after reading the iPXE script page, let me see if I've got this right:

1. spicerack/cumin calls an end-point, say PUT https://<deployment>/ipxe/<serial> with DH URL and parameters
2. DNSv6 returns a URL to iPXE with the value of something like https://<deploy>/ipxe/${serial}
3. iPXE calls that URL, which returns a #!ipxe script, containing a chain url, and passing the parameters specified in step 1.

In T219908#5095526, @crusnov wrote:

1. spicerack/cumin calls an end-point, say PUT https://<deployment>/ipxe/<serial> with DH URL and parameters

No, spicerack will call an endpoint with the FQDN of the host, not the serial and optionally the OS to use if different from the current default (stretch, buster).

2. DNSv6 returns a URL to iPXE with the value of something like https://<deploy>/ipxe/${serial}

DHCPv6 will set the DNS and Boot File URL Option, that will point to a custom built image of iPXE that is setup to call an API with the $serial.

3. iPXE calls that URL, which returns a #!ipxe script, containing a chain url, and passing the parameters specified in step 1.

iPXE will boot, gather the serial and call the API with the $serial and the API will reply the body of the iPXE script with the options to boot from the correct d-i and any eventual additional setting.

Okay the only question that seems open in my mind is how does the service map serial to fqdn?

In T219908#5101343, @crusnov wrote:

Okay the only question that seems open in my mind is how does the service map serial to fqdn?

Querying netbox for the serial, getting the FQDN and checking it that is present in the short-lived cache.