machineInventory label does not accept IPv6 address

[kkaempf]

When a system gets an IPv6 address assigned, elemental-system-agent sentinel runs

elemental-register --label elemental.cattle.io/ExternalIP=192.168.0.48 --label elemental.cattle.io/InternalIP=2a02:810d:8800:1275:d909:3281:bed4:3e41

which is not accepted by elemental-operator

time="2022-08-04T13:22:05Z" level=error msg="failed to update inventory labels: MachineInventory.elemental.cattle.io \"m-raspberrypi-rpi-30303031-3030-3030-6130-393533306132\" is invalid │
│ : metadata.labels: Invalid value: \"2a02:810d:8800:1275:d909:3281:bed4:3e41\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must star │
│ t and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')"                        │

[kkaempf]

It's also strange that the elemental-register call on the client just hangs, without and log output.
Last log line reads

Aug 04 13:22:05 m-raspberrypi-rpi-30303031-3030-3030-6130-393533306132 elemental-system-agent[2502]: time="2022-08-04T13:22:02Z" level=info msg="[24ba0127d95d1a09261cc5689e850cee0e80697715a88d8bcb7ab7b6998f31b0_1:stderr]: time=\"2022-08-04T13:22:02Z\" level=info msg=\"Using TPMHash 2d4bb87828a11cd790634d33e51cfacc9ea1cbb7937eda4e9210eed9c7410f8b to dial wss://192.168.0.33/elemental/registration/pc8slmdvrpwh8tt5tlv79q8s74q2r27sgsz2pxv8bbcpz22kzjbzxm\""

[Itxaka]

1 - Yes, no ipv6 labels should never be passed as a label there, they will never be accepted due to the constraints (no :)
2 - I also have seen it hang up, especially when something is broken. It seems that we are missing some error managing? If it failed we should probably exit instead of hanging out :/

[Itxaka]

we could preserve those by encoding them somehow (base64?) so they are stored, but not sure if they would be used anywhere.

[kkaempf]

if/how these labels/values are used is the actual question 🤔

[kkaempf]

Postponed until after Rancher/Kubernetes fully supports IPv6

[Itxaka]

As far as I could see when I went down that rabbit hole, those labels were not used anywhere. And the only person who added them is no loger available so.... Im not sure they are used anywhere or they were supposed to be something.

When deploying a node, the machine CRD ends up with similar labels (rke.cattle.io/external-ip and rke.cattle.io/internal-ip) but those seems to be set via the deployer (rke/k3s) so Im not even sure those are necessary.

We should think of dropping them until we understand where and how they are needed, so we can add them back if necessary. No point in having extra stuff that we dont understand in the code.

[fgiudici]

As far as I could see when I went down that rabbit hole, those labels were not used anywhere. And the only person who added them is no loger available so.... Im not sure they are used anywhere or they were supposed to be something.

When deploying a node, the machine CRD ends up with similar labels (rke.cattle.io/external-ip and rke.cattle.io/internal-ip) but those seems to be set via the deployer (rke/k3s) so Im not even sure those are necessary.

We should think of dropping them until we understand where and how they are needed, so we can add them back if necessary. No point in having extra stuff that we dont understand in the code.

Completely agree... addressed in #154 (labels removed).
At this point I'm closing this issue (no plan to add back these custom labels). If for some reason these labels are wanted back, please reopen this issue.

[abonillabeeche]

Can we reopen this? Looks like this was an issue for ipv6 and we need this for ipv4 as of now.

[kkaempf]

Can we reopen this? Looks like this was an issue for ipv6 and we need this for ipv4 as of now.

The underlying problem is Kubernetes setting restrictions on label values 🤦🏻

Not sure how to solve this in elemental-operator. (Well, except for wrapping stuff in base64 🤯 )