From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id AE453743EF for <pve-devel@lists.proxmox.com>; Sun, 18 Apr 2021 19:01:48 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9D2BDD418 for <pve-devel@lists.proxmox.com>; Sun, 18 Apr 2021 19:01:48 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id BD67BD3FF for <pve-devel@lists.proxmox.com>; Sun, 18 Apr 2021 19:01:47 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 87F7D4276B; Sun, 18 Apr 2021 19:01:47 +0200 (CEST) Message-ID: <8ed4f090-2021-bbe1-4b7b-ceef71d7f4ff@proxmox.com> Date: Sun, 18 Apr 2021 19:01:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, aderumier@odiso.com Cc: pve-devel <pve-devel@pve.proxmox.com> References: <ee2f7206124fc8adb6d6e9b6691b8388f8622aeb.camel@odiso.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <ee2f7206124fc8adb6d6e9b6691b8388f8622aeb.camel@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.039 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] sdn: looking to unify .cfg files, need opinions about config format X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Sun, 18 Apr 2021 17:01:48 -0000 On 12.01.21 10:19, aderumier@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?