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

[Alexandre DERUMIER]

>>So the idea is to detect network.cfg changes inside pmxcfs, and if we detect changes
>>do a network reload.
>>
>>That way we can apply the config without an additional daemon - sounds good.

Sound good. (so we can do changes in network.cfg.tmp, still have the test button(api call to each nodes), and apply change to network.cfg)


But how does it work ? who is currently listening for changes in pmxcfs ? (through inotify?)


----- Mail original -----
De: "dietmar" <dietmar at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>, "Stoiko Ivanov" <s.ivanov at proxmox.com>, "aderumier" <aderumier at odiso.com>
Envoyé: Jeudi 4 Avril 2019 10:58:09
Objet: Re: [pve-devel] rfc : pve-network : idea to generate and reload config accross the nodes

> Two ideas that came up in my head (not sure if they are good or 
> sensibly implementable): 
> 
> * The networking config has the common property with the corosync 
> configuration (the chicken and egg problem - if it's wrong the 
> cluster cannot push the corrected config to a broken node) so why 
> don't we use the same/a similar mechanism for pushing out changes to 
> the live-config and getting changes from the live-config into the 
> pmxcfs (if we keep the live-data in pmxcfs we know when a write to it 
> happens and can copy it over to /etc/network/interfaces(.d) (and run 
> some ifquery and other tests) before)? Also this would save us from 
> having yet another daemon running in the background and consuming 
> resources. 

So the idea is to detect network.cfg changes inside pmxcfs, and if we detect changes 
do a network reload. 

That way we can apply the config without an additional daemon - sounds good. 

> * from a very quick run with ifquery - it has the ability to read an 
> parse the complete config (including 'source' statements) - so we 
> could use this to get support for '/etc/network/interfaces.d/*' 
> snippets to the API and GUI (IIRC there have been a few requests from 
> users for such a functionality) 

The idea is that we are only responsible for a single file, so 
that makes no sense to me.