Clearing public config fails

[scottyeager]

On mainnet, attempting to clear the public config from a node fails with the errors seen below.

[muhamadazmy]

Actually clearing public config is not supported. The node can't revert having public config cleanly (at the moment).

@delandtj do you think this is a valid use case that need to be handled?

[muhamadazmy]

The problem is the public setup on the node is not revertible on the fly without breaking user networks on the node (wireguard) so to support this we give the farmer an option to modify user setups.

Anyway, the cleanist solution I can think of to is the node can "clean up" config state then reboot itself. This will force the node to have a "working" networking stack. But still affect user networks that was active before this change.

[delandtj]

The public config is solely there for giving networking to the private networks. A Farmer can opt out of that and use his public IP's just for VMs. He can also only add an IPv6 public config (you know, IPv6 first, IPv4 as an afterthought).
Either way, it is advisable to have a few (not necessarily for all nodes in the farm ) IPv4 public addrs on nodes for the Private network mesh and the farmer will earn tokens for that traffic (which can be substantial).
So it's a choice at setup right now, and the necessity to reboot for removing them is not that big of a problem.

[delandtj]

Even more, once some WG connections are established, I would make sure we can't delete the public IP addrs any more, as it will break the networks.

[muhamadazmy]

Yeah, that's the main problem at the moment. Even if we rebooted the node to cleanely rebuild the network. The user still think his network still uses this specific public IP.

The thing is we can't prevent the user from "unsetting" the public config on the chain. and it's gonna be impossible to report back a setup error to the farmer. unless he checks the zos screen maybe.

[muhamadazmy]

I was thinking if both rebooting and/or deleting the public namespace will break user networks anyway. And there is no way we can prevent the farmer from deleting the node public config on the chain then may be it's just better to delete the namespace. user networks will stop working in both cases. it's up to the user to reconfigure his deployments once this happens!

What do u think? @delandtj

[scottyeager]

Thanks for the discussion guys. Not supporting removing the public config without a reboot makes sense to me, but I saw the errors suggesting that Zos was attempting it.

It's definitely bad news if a farmer does this while workloads are using the gateway. With that in mind, it's probably best that a reboot is required, so the farmer has a chance to "undo" before any workloads are broken if they remove the config by mistake.

If we can retain the current behavior while replacing the console error with a message indicating reboot is required to apply changes, I'd say that's a nice solution.

[muhamadazmy]

@scottyeager the reboot is done automatically once the farmer unset the public config. The node clears the config and immediately take the reboot action.

The node need to destroy the public config immediately once it's unset because it's not granted that the ip is reused by something else or another node then can cause even more harm. Hence after config is removed, the node immediately clean up and reboot.

The dashboard of the farm then need to confirm multiple times and give enough info about the consequences of removing or updating the public config.

[scottyeager]

Understood @muhamadazmy. I agree that preventing user error by farmers is better done in the front end. Have opened an issue on the dashboard repo with your recommendation.