[pve-devel] [PATCH common] inotify: fix compatibillity with address + netmask separate passed

[Alexandre DERUMIER]

>>I'm currently looking into this, my plan is, read gives you always the specifc 
>>address, mask and whole cidr separated and write writes it out as you changed 
>>it (adress in cidr format). 

yes, I think it's the right way indeed.


>>Not sure what side should be fixed, but during a stable release I do not want 
>>to change the API return structures such that existing ui needs to adapt, if 
>>avoidable. As this can also break existing external applications - which is 
>>not ideal. So we need to move and check definitively more careful than we did 
>>with this until now. 

yes indeed. sorry about that, I totally miss the "address" return from api and used in networkselector for differents wizard.


----- Mail original -----
De: "Thomas Lamprecht" <t.lamprecht at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>, "aderumier" <aderumier at odiso.com>
Envoyé: Vendredi 13 Mars 2020 08:33:19
Objet: Re: [pve-devel] [PATCH common] inotify: fix compatibillity with address + netmask separate passed

On 3/13/20 8:13 AM, Alexandre DERUMIER wrote: 
> I try to look for the problem with network list api called by networkselector widget 
> 
> I'm not sure if the "address" return from api should be fixed in api, or in Inotify read interface ? 
> (because I think fixing it in read_interface, will rewrite it without cidr in write_interface ?) 

I'm currently looking into this, my plan is, read gives you always the specifc 
address, mask and whole cidr separated and write writes it out as you changed 
it (adress in cidr format). 


> Also, for multiple ips, networkselector will need to be fixed too to handle multiple ips 
> 


Not sure what side should be fixed, but during a stable release I do not want 
to change the API return structures such that existing ui needs to adapt, if 
avoidable. As this can also break existing external applications - which is 
not ideal. So we need to move and check definitively more careful than we did 
with this until now.