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 A8A76610AD for ; Sat, 26 Sep 2020 07:30:20 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 963B81FD15 for ; Sat, 26 Sep 2020 07:29:50 +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 C70AD1FD09 for ; Sat, 26 Sep 2020 07:29:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id D932D1C3C9C8; Sat, 26 Sep 2020 07:29:47 +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 xTHPzTpl8kPk; Sat, 26 Sep 2020 07:29:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id BB7311C3C9C5; Sat, 26 Sep 2020 07:29:47 +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 lA1sh-LmDMwZ; Sat, 26 Sep 2020 07:29:47 +0200 (CEST) Received: from mailpro.odiso.net (mailpro.odiso.net [10.1.31.111]) by mailpro.odiso.net (Postfix) with ESMTP id A28C21C3C9C4; Sat, 26 Sep 2020 07:29:47 +0200 (CEST) Date: Sat, 26 Sep 2020 07:29:47 +0200 (CEST) From: Alexandre DERUMIER To: Thomas Lamprecht Cc: Proxmox VE development discussion Message-ID: <382730821.1271374.1601098187379.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> 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: sXjYRij9FakGWyqcXs60JdIrh3pXrA== X-SPAM-LEVEL: Spam detection results: 0 AWL 0.401 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: Sat, 26 Sep 2020 05:30:20 -0000 >> >>Having two versions, the enacted and a pending, could be enough >> >>* if both are the same all is applied >>* if pending is newer we can show it, but new changes should not further >> increase the version, they are seen as part of the current pending stuf= f. >>* if pending is older, bug but don't care? >>So on each change we bump $pending to $enacted + 1 (*not* $pending++) aft= er we >>wrote the changes out. We could make /etc/pve/sdn/.version more structure= d, either >>json map or something like: >>enacted=3D3 >>pending=3D4 >> >>(json could be more flexible) >> >>An apply sets $enacted to $pending once finished (without errors). >> >>This would be simple, not much to track but still give the admin info if = anything >>is pending. What do you think? I was thinking about another way, where user could also manualing edit /etc= /pve/sdn/*.cfg files (or with some automations tools like puppet,ansible,... to manage their net= work). I was think about this: sdn/*.cfg are the pending config, we don't increase any version counter h= ere when when apply config, we increase version but also we generate a json dum= p of configurations (vnets,zones,controllers,subnets,...). (instead .version file, maybe create a .running-config file, with the json = + version in the json) This json dump of configuration with be the source to generate the local co= nfiguration of each node. 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 for= a specific element) and user is still able to modify *.cfg manually. what do you think about this ? ----- Mail original ----- De: "Thomas Lamprecht" =C3=80: "aderumier" Cc: "Proxmox VE development discussion" Envoy=C3=A9: Vendredi 25 Septembre 2020 11:06:10 Objet: Re: [pve-devel] [PATCH v8 pve-network 09/25] api2: increase version = on apply/reload only On 25.09.20 10:35, Alexandre DERUMIER wrote:=20 >>> but how do you detect pending changes now?=20 >=20 > Well, the feature was mainly to detect pending change after reload.=20 > if a reload don't have applied correctly on a node, or if a node was down= .=20 >=20 > I don't known if we want to display to user "pending config" changes, not= yet applied ?=20 I'd like to have that.=20 >=20 > Befor this commit, It's displaying warning after any config change,=20 > and it's difficult to known if a problem occur after the reload.=20 On 25.09.20 10:39, Alexandre DERUMIER wrote:=20 > also,=20 >=20 > for example, when you add a new vnet in a zone,=20 >=20 > it was displaying a warning all vnets/zones for pending changes.=20 >=20 > as I don't have enough granularity currently (a global version info in /e= tc/network/interfaces.d/sdn, or we should have some kind of versioning info= by vnet in /etc/network/interfaces.d/sdn)=20 >=20 >=20 Having two versions, the enacted and a pending, could be enough=20 * if both are the same all is applied=20 * if pending is newer we can show it, but new changes should not further=20 increase the version, they are seen as part of the current pending stuff.= =20 * if pending is older, bug but don't care?=20 So on each change we bump $pending to $enacted + 1 (*not* $pending++) after= we=20 wrote the changes out. We could make /etc/pve/sdn/.version more structured,= either=20 json map or something like:=20 enacted=3D3=20 pending=3D4=20 (json could be more flexible)=20 An apply sets $enacted to $pending once finished (without errors).=20 This would be simple, not much to track but still give the admin info if an= ything=20 is pending. What do you think?=20