From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E787D61313 for ; Sun, 27 Sep 2020 08:28:08 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D5BA524C7A for ; Sun, 27 Sep 2020 08:28:08 +0200 (CEST) Received: from mailpro.odiso.net (mailpro.odiso.net [89.248.211.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 491C724C6D for ; Sun, 27 Sep 2020 08:28:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id DAF101C62E52; Sun, 27 Sep 2020 08:27:57 +0200 (CEST) Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xh-ixj5bbLOC; Sun, 27 Sep 2020 08:27:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id BC3951C62E53; Sun, 27 Sep 2020 08:27:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at mailpro.odiso.com Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 598u7KrA8w1W; Sun, 27 Sep 2020 08:27:57 +0200 (CEST) Received: from mailpro.odiso.net (mailpro.odiso.net [10.1.31.111]) by mailpro.odiso.net (Postfix) with ESMTP id A68881C62E52; Sun, 27 Sep 2020 08:27:57 +0200 (CEST) Date: Sun, 27 Sep 2020 08:27:57 +0200 (CEST) From: Alexandre DERUMIER To: Thomas Lamprecht Cc: Proxmox VE development discussion Message-ID: <1423341987.1284761.1601188077436.JavaMail.zimbra@odiso.com> In-Reply-To: References: <20200924084054.611548-1-aderumier@odiso.com> <20200924084054.611548-10-aderumier@odiso.com> <0660b2c5-c733-7f3c-42ea-52425323fc1a@proxmox.com> <1270427221.1250623.1601022902478.JavaMail.zimbra@odiso.com> <2072648578.1250758.1601023192168.JavaMail.zimbra@odiso.com> <382730821.1271374.1601098187379.JavaMail.zimbra@odiso.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3866 (ZimbraWebClient - GC83 (Linux)/8.8.12_GA_3844) Thread-Topic: api2: increase version on apply/reload only Thread-Index: s6rjFNVpffeiwl/CZs7cTOScYbutxA== X-SPAM-LEVEL: Spam detection results: 0 AWL 0.398 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no 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] [PATCH v8 pve-network 09/25] api2: increase version on apply/reload only X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 06:28:09 -0000 >>But, do you think complex setups could outgrow the 512k pmxcfs file limit= for >>big setups I think it should be enough, zones/controllers/ipam/dns should be small, vnets + subnets should be the b= iggest part. around 50bytes by vnet and around 80bytes by subnet with all options. so around 150bytes for 1vnet+1subnet., this should give use around 3000vne= ts/subnets. I think it's enough the current cluster size (20-40nodes max), so maybe 500= 0vms max by cluster, 3000vnets should be enough. ----- Mail original ----- De: "Thomas Lamprecht" =C3=80: "Alexandre Derumier" Cc: "Proxmox VE development discussion" Envoy=C3=A9: Samedi 26 Septembre 2020 08:51:42 Objet: Re: [pve-devel] [PATCH v8 pve-network 09/25] api2: increase version = on apply/reload only On 26.09.20 07:29, Alexandre DERUMIER wrote:=20 > I was thinking about another way, where user could also manualing edit /e= tc/pve/sdn/*.cfg files=20 > (or with some automations tools like puppet,ansible,... to manage their n= etwork).=20 >=20 > I was think about this:=20 >=20 > sdn/*.cfg are the pending config, we don't increase any version counter h= ere=20 >=20 > when when apply config, we increase version but also we generate a json d= ump of configurations (vnets,zones,controllers,subnets,...).=20 > (instead .version file, maybe create a .running-config file, with the jso= n + version in the json)=20 >=20 >=20 > This json dump of configuration with be the source to generate the local = configuration of each node.=20 >=20 >=20 > Like this, we could also display pending change for each vnets,zones,...(= or a simple display a "status:pending" in a new column in the config grid f= or a specific element)=20 > and user is still able to modify *.cfg manually.=20 >=20 > what do you think about this ?=20 sounds good to me.=20 But, do you think complex setups could outgrow the 512k pmxcfs file limit f= or=20 big setups?