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

[Tom Weber]

Am Mittwoch, den 03.04.2019, 07:03 +0200 schrieb Dietmar Maurer:
> > I think, something easy, is that we could have a copy of each
> > /etc/network/interfaces of each node in
> > /etc/pve/nodes/<nodename>/interfaces.
> > (could be done we a change is done in gui local netowrk, or local
> > network daemon copy it at regular interval in case of manual change
> > for example).
> > 
> > 
> > Like this, it's very easy, when a network change is one at
> > datacenter level, we can directly test it on all network interfaces
> > of all nodes ( /etc/pve/nodes/*/interfaces). (in the api endpoint),

/etc/network/interfaces is only a small part of actual network
configuration.

> I is still unclear to me how you do those tests? AFAIK, ifreload does
> not have a --dry-run option. Even when it has such option, it would
> need access to the local node? (to see what interfaces exists, ...).
> 
> 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.
> 
> > and then write directly the conf. (no need vnet.new tmp file).
> 
> 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.

Probably helpful but as you said, network configuration can be really
complex (good luck finding my tinc bridges in the interfaces file - let
alone developing a test).

Why not have a static (host specific) part that never ever gets touched
by pve. Usually all thats needed to get the node into the cluster.
Additional parts can be managed via the cluster - selectable on which
nodes (including all) to apply.
If you select/mark a node, try to apply, if that fails, fall back to
your static basic configuration above and show errors so the admin can
fix, ideally with the node still in the cluster.

So you can test on single test-nodes if you need or apply on all if
you're sure about your changes.

We don't try to prevent shooting our feet at other places either (like
firewalling).

Best,
  Tom