[pve-devel] sdn: looking to unify .cfg files, need opinions about config format

[Thomas Lamprecht]

On 12.01.21 10:19, aderumier at odiso.com wrote:
> Hi,
> 
> I'm looking to unify sdn .cfg files with only 1 file,
> with something different than section config format.
> 
> We have relationship like  zones->vnets->subnets,
> so I was thinking about something like this:
> 
> 
> 
> [zone myzone]
>    type: vxlan
>    option1: xxx
>    option2: xxx
> [[vnet myvnet]]
>    option1: xxx
>    option2: xxx
> [[[subnet 10.0.0.0/8]]]
>    option1: xxx
>    option2: xxx
> 
> 
> [controller  mycontroller]
>    type: evpn
>    option1: xxx
>    option2: xxx
> 
> [dns  mydns]
>    type: powerdns
>    option1: xxx
>    option2: xxx
> 
> 
> What do you think about this ?

That looks like section config, just spelled differently?

But yes, the way section config does schema and types are not ideal when combined
with quite different things.

Maybe we should really just go the simple way and keep it separated for now.

For zones it works good this way, there exist different types and we can use that as
section config type. Subnets and vnets could be combined as vnets are really not that
specially I guess?

We had a mail about what would be Ok to merge, but I do not remember/find it anymore...

> 
> Another way could be a simple yaml config file. (but I think it's not
> really matching currents proxmox configs formats)
> 

I do not like yaml to much, it looks simple first but can do way to much (turing
complete, IIRC) and we do not really use it anywhere atm., so that would mean lots
of new tooling/work to do to handle it sanely and as first-class citizen in PVE
stack...

My goal would be to do a pve-network bump at end of next week, and for that we
need pve-cluster bump.

Currently there we get three new configs:

1. ipams, different management plugins (types), so OK to be own section config
2. dns, different, APIs/DNS servers (types), so OK to be own section config
3. subnets, only one type, or?

hmm, rethinking this now it could be OK to keep as is... While subnets could
possibly be merged into vnets, there's a mediocre benefit there, API could
maybe even get more complicated?

If we'd bump now the biggest thing missing is applying an IP to a VM and CT.

For a CT we can quite easily do it.

For a VM we could even need to support different ways?

* DHCP (?)
* cloudinit
* would the qemu-guest-agent work too?

IMO that's the biggest thing left, or what do you think?