[pve-devel] [PATCH v8 pve-network 09/25] api2: increase version on apply/reload only

Alexandre DERUMIER aderumier at odiso.com
Sat Sep 26 07:29:47 CEST 2020


>>
>>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 at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "Proxmox VE development discussion" <pve-devel at 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? 





More information about the pve-devel mailing list