[pve-devel] rfc : pve-network : idea to generate and reload config accross the nodes

[Dietmar Maurer]

> >>I is still unclear to me how you do those tests? AFAIK, ifreload does not have a --dry-run option. 
> with ifupdown2, ifreload -a --no-act.
> (+ tests with our currrent read_networt_interface code)

Ok, thanks. (This flag is not documented in the manual page). 

> 
> >>Even when it has such option, it would need access to the local node? (to see what interfaces exists, ...). 
> Yes, that's why my last proposition what to have a of local copy configuration to /etc/pve/. (to be able to test with only 1api call, without calling each node)

My point is that you need more info, for example existing interfaces (/proc/net/dev), or locally assigned ip addresses or routes. A copy of /etc/network/interfaces does not provide all necessary information.

> >>I am not sure it this is a real problem. I think the cluster wide vnet config is the relevant config. If a node is unable to apply that config, the node needs to get fixed. 
> >>I think of this like deploying a network configuration with ansible (or other tools). 
> 
> Do you have an idea where to report a local error configuration ? 

Maybe an extra file inside /etc/pve/nodes/<node>/ ...

(not sure about that).

> I was thinking about diplaying transport/vnets in main tree (like storage), and display error on it.

You mix different things here. The configuration is cluster wide (for all nodes). Opposed to that, vnet status is per node.

We have the same thing with storages, so maybe we can implement it the same way? Simply display vnet status in the left tree (like we do for storage status)?

> (maybe with compare the running local network config and what is defined in /etc/pve/network/ ). (for presentation, maybe like a storage with volumes, we could have a transport with vnets). Not sure it's a good idea ?

Sorry, I do not really understand that suggestion?

> >>So if you really need/want to test before apply, we could add and API call for that: 
> >>POST /api2/json/nodes/<node>/test_network_changes 
> >>We can then add a TEST button to the GUI, or call those this test API on all nodes before we apply changes. 
> 
> Ok, I was not sure about this way. So let's go for this.
> 
> 
> 
> 
> >>I think network configuration is really complex, and we should avoid to do anything automatically. 
> >>I would prefer and "APPLY" button, so that I have full control over when network changes happen. 
> >>Maybe an extra "TEST" button would be also helpful. 
> 
> Ok, I'll look this way.

OK