operator: protocol on the websocket channel for machine registations

[fgiudici]

PR #143 introduces a (new) protocol for the operator-register <-> operator communication.
This discussion is meant to discuss and review the protocol from a functional PoV, in order to have something future proof, easily extensible that will keep backward compatibility.

The communication channel is used for:

1. registering a new host to the operator and retrieving from the operator the elemental configuration for the OS installation
2. updating the labels (the machine state) on the MachineInventory

The proposed protocol works in two steps: first it performs Authentication, then (if Authentication is successful) it allows the client (the registering host) to request services to the server (the operator).

1. Authentication: the client puts an Authentication HTTP header containing the Authentication Data (right now, only TPM attestation is supported). Message exchanges follow to complete the authentication (challenge from the server, challenge response from the client). The client will wait for the authentication result from the server: MsgReady means the authentication was successful and the client is enabled to require services to the server (operator), otherwise the communication is over.
2. Services: the server will wait for service request from the authenticated client. The available services are:
   • MsgSmbios : the server listens to the SMBIOS data from the client and generates the MachineInventory name. It sends back a MsgReady and waits for the next service request.
   • MsgLabels: the server listens for new labels to be added to the MachineInventory. Replies with MsgReady and waits for the next service request.
   • MsgGet: the server commits the MachineInventory changes collected (if any), sends back the elemental configuration to the client and closes the connection. Right now this is the only way to successfully terminate the protocol.

The list of protocol messages is defined as:

const (
	MsgUndefined MessageType = iota
	MsgReady
	MsgSmbios
	MsgLabels
	MsgGet
	MsgLast = MsgGet // MsgLast must point to the last message
)

and could be easily extended by adding more messages on the bottom. The MsgLast willl track the latest known message allowing to easily extend the protocol by keeping backward compatibility.

[davidcassany]

and could be easily extended by adding more messages on the bottom. The MsgLast willl track the latest known message allowing to easily extend the protocol by keeping backward compatibility.

Interesting pattern 🤔 👍

Thanks a lot for the explanation, with it and after merging #140 and #141 Now I could really follow #143

Great work!

out-of-topic: does anyone know what the up arrow on the bottom left corner of the discussion means...? 😅

[fgiudici]

and could be easily extended by adding more messages on the bottom. The MsgLast willl track the latest known message allowing to easily extend the protocol by keeping backward compatibility.

Interesting pattern thinking +1

Thanks a lot for the explanation, with it and after merging #140 and #141 Now I could really follow #143

Great work!

out-of-topic: does anyone know what the up arrow on the bottom left corner of the discussion means...? sweat_smile

🤔 🔍 after a quick google search, I think it is to "upvote", i.e., to vote for the most interesting discussions... guess it would help to sort out the most important ones 🤷🏼‍♂️

[kkaempf]

I can already see a MsgReadLabel on the horizon for the client to read a MachineInventory label.:wink: