[FEATURE] BSS should communicate with SMD when setting/getting boot parameters/scripts

[synackd]

Is your feature request related to a problem? Please describe.

BSS currently supports setting boot parameters for MAC addresses, NIDs, and xnames, but has no ability to map between these. For example, if boot parameters are set for MAC address de:ca:fc:0f:fe:ee and different boot parameters are set for NID 1 and that MAC address corresponds to a node component in SMD with NID 1, BSS would have no idea that they are the same and treat them as separate entities.

Also, it is pretty useless to add boot parameters into BSS by xname or NID because of this disconnect because BSS only checks the MAC address when fetching the boot script. For example, if one adds boot parameters for NID 2 and this NID corresponds with a valid MAC address in SMD, if that MAC address requests a boot script, BSS will return the default (unknown) boot script.

This dynamic makes grouping boot parameters by group impossible in the current implementation.

Describe the solution you'd like

BSS should be able to communicate with SMD to fetch the list of groups, components and ethernet interfaces to be able to map to MAC addresses. Some examples for how this could work are listed below, but feedback from other admins on what they would expect are welcome:

Example 1: Boot Parameters for Group

Assumptions:

• The following components are present in the "compute" group in SMD:
  • xname=x1000c1s1b0n0 nid=1
    • has an ethernet interface with MAC de:ca:fc:0f:fe:ee
  • xname=x1000c1s1b1n0 nid=2
    • has an ethernet interface with MAC de:ad:be:ee:ee:ef
• BSS is empty

Admin attempts to add boot parameters for group "compute":

1. Send BSS payload for name=compute kernel=https://example.org/kernel initrd=https://example.org/initrd params="nomodeset".
2. BSS sets kernel=https://example.org/kernel initrd=https://example.org/initrd params="nomodeset" for name "compute".

Node in "compute" group tries to fetch boot script:

1. BSS checks SMD groups to see if component with an ethernet interface with the requesting MAC is in the "compute" group. If it exists in the group, continue.
2. BSS serves boot parameters that are stored for name "compute" in BSS.

Example 2: Boot Parameters for Xname/NID

Setting boot parameters for an Xname or NID uses the same concepts in Example 1.

Assumptions:

• The following component is present in SMD:
  • xname=x1000c1s1b0n0 nid=1
    • has an ethernet interface with MAC de:ca:fc:0f:fe:ee
• BSS is empty

Admin attempts to add boot parameters for xname x1000c1s1b0n0:

1. BSS checks if this component exists in SMD and gets its NID and MAC addresses. If it exists, continue.
2. BSS checks if a boot configuration exists for this component. If not, continue.
3. BSS adds boot parameters specified, setting them for MAC address de:ca:fc:0f:fe:ee, NID 1, and xname x1000c1s1b0n0 (all of these fields are populated)

Updating for an xname/NID/MAC would be a similar process.

Describe alternatives you've considered

An alternative would be not storing group name in BSS and only checking SMD for it, only storing xname/NID/MAC.

Additional context

I haven't checked if this is only the case for the Postgres backend or if this is also an issue with the EtcD backend.