networking: use the main registration websocket channel for network data

[fgiudici]

Now the network data is piggybacked to the elemental data during registration.
This way the registering client doesn't need to open a separate connection after the registration is done.

[anmazzotti]

Appending the serialized NetworkConfig to the MachineRegistration may create collisions in the future. I feel this is a bit too uncharted territory. The new data should have a proper schema at very least.

[anmazzotti]

This may be problematic.
The registration (what's given in the data ) already contains the networkTemplate.
Some keys are colliding with the network config, so not sure how this is supposed to work.

We do need a different API in here, this should be an object, not appended. Most likely we need a wrapper struct that contains both the MachineRegistration (like data), but additionally it contains the NetworkConfig in some nested field as well.

[fgiudici]

This may be problematic. The registration (what's given in the data ) already contains the networkTemplate. Some keys are colliding with the network config, so not sure how this is supposed to work.

well, actually no, they do not collide, since yaml data is structured: data here holds elemental, network and cloud-config while netData adds ipAddresses and config sections.

We do need a different API in here, this should be an object, not appended. Most likely we need a wrapper struct that contains both the MachineRegistration (like data), but additionally it contains the NetworkConfig in some nested field as well.

We have multiple problem we inherited with the "original" protocol, in particular here sharing the data structure used for defining the elemental config in the CRDs to also send installation configuration.
We also have the end of connection bound to sending back the full installation config (sob).

The idea here was to avoid adding another "get config and close" API in the protocol and have to maintain two of them... we already did in the past, was not great.

All the data is serialized in bytes, appending two configs is not at all a programming pattern, not something that would in general recommend, but for this case it will allow to keep the current API, piggyback network information if available, and would work with old register client seamlessly thanks at how yaml (and json) marshaling works.

[anmazzotti]

This may be problematic. The registration (what's given in the data ) already contains the networkTemplate. Some keys are colliding with the network config, so not sure how this is supposed to work.

well, actually no, they do not collide, since yaml data is structured: data here holds elemental, network and cloud-config while netData adds ipAddresses and config sections.

We do need a different API in here, this should be an object, not appended. Most likely we need a wrapper struct that contains both the MachineRegistration (like data), but additionally it contains the NetworkConfig in some nested field as well.

We have multiple problem we inherited with the "original" protocol, in particular here sharing the data structure used for defining the elemental config in the CRDs to also send installation configuration. We also have the end of connection bound to sending back the full installation config (sob).

The idea here was to avoid adding another "get config and close" API in the protocol and have to maintain two of them... we already did in the past, was not great.

All the data is serialized in bytes, appending two configs is not at all a programming pattern, not something that would in general recommend, but for this case it will allow to keep the current API, piggyback network information if available, and would work with old register client seamlessly thanks at how yaml (and json) marshaling works.

Agreed, not having to reopen the websocket is indeed nice.
For the data I see it now it's how we are already doing it, nevermind. It is not going to collide indeed.

[anmazzotti]

LGTM