SP broadcast could include baseboard model, revision, and ID

[jclulow]

At present the SP announces its presence periodically via a UDP broadcast sent to port 8888. The packet contents currently appears to include:

• the base MAC address (which we would have gotten from the VPD)
• the image ID (as you would see from humility manifest | grep image.ID)

At the moment, pilot maintains a database that maps base MAC to the Gimlet or Sidecar serial number. Without this database we cannot cheaply infer the identity of a particular SP -- we would need to make a request to each one, or we would need to do something less stateless than what we are doing now. The upshot of the database is that old images don't know the identity of equipment manufactured after the last time macdb.txt was updated.

It would be really neat if we could extend the broadcast slightly to include the following information we can otherwise get from macdb.txt:

• baseboard model (e.g., 913-0000019)
• baseboard revision (e.g., 6)
• baseboard identifier (e.g., BRM42220021)

It would also be acceptable to just include the BARC string directly from the VPD if you'd prefer (e.g., 0XV1:9130000019:006:BRM42220021) but I suspect it's already parsed inside the SP?

As a note for control plane implementation: it would probably be incorrect to depend on this broadcast for identity for something like MGS or Nexus. In the pilot case we are in an engineering/test rack where we don't care about the security implications, but in production this message is totally unauthenticated and easily spoofable by someone who can physically alter the rack.

[jgallagher]

It would also be acceptable to just include the BARC string directly from the VPD if you'd prefer (e.g., 0XV1:9130000019:006:BRM42220021) but I suspect it's already parsed inside the SP?

It is indeed; if we want udpbroadcast to depend on control-plane-agent, it could call ControlPlaneAgent.identity which returns the three parsed fields. This would mean udpbroadcast would get wedged if control-plane-agent gets wedged, though (e.g., earlier today #1218)

[jclulow]

Could it call that once, and cache the result there after? It does seem like it would be best if the broadcast task didn't wedge when other tasks do.

[jgallagher]

We should probably do this as an addon to #1197 - @cbiffle suggests there that we have a dedicated caching task (which sends no IPCs and should never fault), at which point udpbroadcast could be another client of it (in addition to net and control-plane-agent).