public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Alexandre DERUMIER <aderumier@odiso.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v8 pve-network 09/25] api2: increase version on apply/reload only
Date: Sat, 26 Sep 2020 07:29:47 +0200 (CEST)	[thread overview]
Message-ID: <382730821.1271374.1601098187379.JavaMail.zimbra@odiso.com> (raw)
In-Reply-To: <dc625ce7-2eda-38e1-cb66-73432f339856@proxmox.com>

>>
>>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 stuff.
>>* if pending is older, bug but don't care?

>>So on each change we bump $pending to $enacted + 1 (*not* $pending++) after we
>>wrote the changes out. We could make /etc/pve/sdn/.version more structured, either
>>json map or something like:
>>enacted=3
>>pending=4
>>
>>(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 network).

I was think about this:

sdn/*.cfg  are the pending config,  we don't increase any version counter here

when when apply config, we increase version but also we generate a json dump 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 configuration 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" <t.lamprecht@proxmox.com>
À: "aderumier" <aderumier@odiso.com>
Cc: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Envoyé: 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: 
>>> but how do you detect pending changes now? 
> 
> Well, the feature was mainly to detect pending change after reload. 
> if a reload don't have applied correctly on a node, or if a node was down. 
> 
> I don't known if we want to display to user "pending config" changes, not yet applied ? 

I'd like to have that. 

> 
> Befor this commit, It's displaying warning after any config change, 
> and it's difficult to known if a problem occur after the reload. 

On 25.09.20 10:39, Alexandre DERUMIER wrote: 
> also, 
> 
> for example, when you add a new vnet in a zone, 
> 
> it was displaying a warning all vnets/zones for pending changes. 
> 
> as I don't have enough granularity currently (a global version info in /etc/network/interfaces.d/sdn, or we should have some kind of versioning info by vnet in /etc/network/interfaces.d/sdn) 
> 
> 

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 stuff. 
* if pending is older, bug but don't care? 

So on each change we bump $pending to $enacted + 1 (*not* $pending++) after we 
wrote the changes out. We could make /etc/pve/sdn/.version more structured, either 
json map or something like: 
enacted=3 
pending=4 

(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? 




  reply	other threads:[~2020-09-26  5:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24  8:40 [pve-devel] [PATCH v8 pve-network 00/25] sdn: add subnets management Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 01/25] add subnet plugin Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 02/25] vnets: add subnets Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 03/25] add subnets verifications hooks Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 04/25] zones: simple|evpn: add gateway ip from subnets to vnet Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 05/25] zone: add vnet_update_hook Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 06/25] vnets: subnets: use cidr Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 07/25] subnet: fix on_delete_hook Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 08/25] api2: subnet create: convert cidr to subnetid Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 09/25] api2: increase version on apply/reload only Alexandre Derumier
2020-09-25  7:15   ` Thomas Lamprecht
2020-09-25  8:35     ` Alexandre DERUMIER
2020-09-25  8:39       ` Alexandre DERUMIER
2020-09-25  9:06         ` Thomas Lamprecht
2020-09-26  5:29           ` Alexandre DERUMIER [this message]
2020-09-26  6:51             ` Thomas Lamprecht
2020-09-27  6:27               ` Alexandre DERUMIER
2020-09-28  5:13                 ` Alexandre DERUMIER
2020-09-28  7:28                   ` Thomas Lamprecht
2020-09-28  8:20                     ` Alexandre DERUMIER
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 10/25] add ipams plugins Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 11/25] add pve internal ipam plugin Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 12/25] vnets: find_free_ip : add ipversion detection Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 13/25] vnets: add add_ip Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 14/25] vnets: add del_ip + rework add_ip/find_free_ip Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 15/25] add dns plugin Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 16/25] Fix vnet gateway for routed setup + /32 pointopoint subnet Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 17/25] ipam : pveplugin : fix find_next_free_ip Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 18/25] add vnet to subnets && remove subnetlist from vnet Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 19/25] zones: evpn|simple: add snat iptables rules Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 20/25] subnet: disable route option for now and add dns domain format Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 21/25] dns: fix reverse dns Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 22/25] subnets: move api to /sdn/vnet/<vnet>/subnets && make vnet option not optionnal Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 23/25] zones: evpn : fix raise exception Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 24/25] subnet: make ipam not optionnal and use pve ipam as default Alexandre Derumier
2020-09-24  8:40 ` [pve-devel] [PATCH v8 pve-network 25/25] don't allow subnets on vlanware vnet Alexandre Derumier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=382730821.1271374.1601098187379.JavaMail.zimbra@odiso.com \
    --to=aderumier@odiso.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal