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

[Alexandre DERUMIER]

> >>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), 
Yes, indeed.


>>or locally assigned ip addresses or routes. A copy of /etc/network/interfaces does not >>provide all necessary information. 

What do you mean by locally assigned ?  manually with ip command ?
because it's be overwritten by network service restart/reload. (if the interface is define in /etc/network/interfaces)


> 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? 

I mean, it's indeed like for storage, but we could have a lots of vnets. (for example, I'm using around 150 differents vlans in production)
As the vnets are alwary associated to 1 transport, my idea was to only display transports in the main tree (on each node), and then when you click an transport, you display in the
right panel, the list of vnets.  (to compare with storage,  a transport = storage, and when you click on storage, you display the volumes (or vnet in this case).

In my cas, this is only to avoid to display 150 vnets * 20 nodes.


Maybe another way, to no flood the tree, is to have a child "vnet" on each node, and then under this child, add all vnets (and keep the parent close by default)




----- Mail original -----
De: "dietmar" <dietmar at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Jeudi 4 Avril 2019 07:48:54
Objet: Re: [pve-devel] rfc : pve-network : idea to generate and reload config accross the nodes

> >>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