PoC: BIOS version & settings management

[aobort]

Proposed Changes

This PR contains PoC implementation for management of server's BIOS version and settings:

• API types
• Controller
• Service managing tasks (scan, apply settings, update version)

This approach fully separate concrete job implementation from the reconciliation flow.

To discuss

BootOrder

Do we need to move boot order field from server to serverBIOS CR? Semantically, yes. As it's one of BIOS settings.

BIOS settings in .status

From my perspective, it reasonable to reflect in .status.bios.settings only those settings which are set in .spec.bios.settings. This will make comparison of .spec and .status much easier.

Storing bios settings

Do we need custom type for bios setting:

type SettingsEntry struct {
    // +required
    Name string `json:"name"`
    
    // +required
    Value string `json:"value"`
        
    // +optional
    Unsupported bool `json:"unsupported,omitempty"`
}

to avoid attempting to apply settings which are not supported in the specified BIOS version? I.e.:

apiVersion: metal.ironcore.dev/v1alpha1
kind: ServerBIOS
metadata:
  name: foo
spec:
  scanPeriodMinutes: 30
  serverRef:
    name: bar
  bios:
    # changing both version and 'unsupported' flag in the same time
    version: 1.0.0  --> 2.0.0
    settings:
    - name: legacyboot
      value: enabled
      unsupported: false  --> true

upgrading from version 1.0.0 to 2.0.0 will lead to the bios setting responsible for legacy boot is deprecated/unsupported, thus it is explicitly marked as unsupported and will not be considered during settings applying.

[stefanhipfel]

idea: would be great to have an endpoint to get all current active tasks from the sync.Map

[aobort]

@stefanhipfel thanks for idea.
Totally agree. Also we might need to implement queues for requests, rate limiting, retrying on client side and tons of other stuff. Apart from that, I'd also like to generate http API from spec without hardcoding endpoints.

But for now, I think the main goal is to come to agreement - will we proceed further with this design or not.

[stefanhipfel]

do we need to stop the server reconciliation in the meantime?
e.g.: do not allow serverClaim

[aobort]

No, we do not need to stop server's reconciliation - we do not care what is the state of the server. But we need to stop serverBIOS reconciliation, bc both BIOS version and settings update will lead to server reboot. So for now we decided that we'll work only with servers which are in "Available" state.

If the server is in available state, then we'll need to set it to "maintenance". But the servers' maintenance topic is still open. Thus I decide to not to mention it at all for now.

#76

[stefanhipfel]

ok but during a serverBios update, someone could still claim the server. Any available server can be claimed

[aobort]

ok but during a serverBios update, someone could still claim the server. Any available server can be claimed

@stefanhipfel that's a good point. However, I do not really like the idea that the serverBIOS controller would change server's state to exclude it from reconciliation. For number of reasons the server's "owner" might want to postpone the update. Especially in terms of version upgrade.
I could add the "Maintenance" state for server and update the controller, so it will check whether server's state is "Maintenance" instead of "Available".

[stefanhipfel]

@aobort yes i think so as well, that the serverBIOS should not change a server's state.

Alternative idea: the server reconciler checks on the serverBIOS state.

[stefanhipfel]

overall I think the POC looks ok

[stefanhipfel]

ok but during a serverBios update, someone could still claim the server. Any available server can be claimed

[stefanhipfel]

we could add the current state of the bios task

[stefanhipfel]

@aobort overall I think the POC looks good.

Next step would be to gather some improvements and test it with real examples!