Re: [pve-devel] [PATCH v2 pve-container] POC : add/del/update ip from vnet-subnet-ipam

[Alexandre DERUMIER <aderumier@odiso.com>]

Hi Thomas,

I have begin to work on new subnet panel (like ipset),

it's working fine.

I have also changed the api endpoint to /cluster/sdn/vnets/<vnetid>/subnets/<subnetid>

I'll try to send patch next week.



About your problem with ipam, and the gateway.
I have found bug, if you create first the subnet + gateway,  then add the ipam option later,
the ip of the gateway was not registered.

Do you think it could be great to make ipam option mandatory ? (and defaulting to internal pve ipam ?)
without the need to declare pve ipam in ipams.cfg.  
(Like this, ipams.cfg is only for external ipams)


I think also than ipam driver should not be changed/removed from subnet creation, or it'll be possible
to have conflict/duplicated ips.



----- Mail original -----
De: "aderumier" <aderumier@odiso.com>
À: "Thomas Lamprecht" <t.lamprecht@proxmox.com>
Cc: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Envoyé: Mardi 8 Septembre 2020 10:58:53
Objet: Re: [pve-devel] [PATCH v2 pve-container] POC : add/del/update ip from vnet-subnet-ipam

>>I'd like to have stuff in priv/ folder prefixed with a directory 
>>namespace, maybe "sdn" here. 

Ok,I'll add the extra /sdn/ 

(for your problem, maybe look if the gateway ip is present in the ipam.db) 

>>Besides that, how big can this get on huge setups? We only can have 512k files 
>>for now. 
currently, it's just a perl hash converted to json with ip list. (so 32bits by ipv4, and 128bits by ipv6). 
So I think it could be ok for common cluster ? 



>>Could it make sense to have subnets and vnets at least in the same section config, 
>>with different types? (a bit like storage.cfg) So that we reduce the configuration 
>>file amount a bit. 

yes, I think it's possible. I'll look to see how to implement that. 
do you want to have 1 api endpoint for both subnets && vnets ? 

>>Maybe we could also visualize this in the gui a bit "easier". 
>>We could merge VNet and SubNet management into one panel, maybe with split view 
>>like FW ipsets 

That's a really good idea ! Like it :) 
I'll look at FW ipset extjs implementation. 

>>you won't have the same subnet in different VNets after all,or ? 

Yes, currently I manage only 1subnet-1vnet. 
I don't think users will used same subnet multiple times, until they used vrf for routed vnet or isolated bridge. 


>>We could also merge DNS and IP management into one panel, maybe with split view 
>>like HA or vertical like FW ipsets. 
>> 
>>But this is not too relevant for now, can always be fine tuned once the API/backend 
>>stuff is in. 

Ok, no problem. 


>>On another note, are there some unit/regressions tests for this stuff? 
>>Would give a bit more confidence with this. 

No sorry. I have done tests manually currently. 
I don't know too much how to implement the unit tests, but I'll try too see what can be done. 

>>skimming through the code currently, seems mostly OK for now, need to think a bit 
>>about how the general concepts are implemented and if that fits all OK. 

Thanks for the review && comments ! 




----- Mail original ----- 
De: "Thomas Lamprecht" <t.lamprecht@proxmox.com> 
À: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>, "aderumier" <aderumier@odiso.com> 
Envoyé: Mardi 8 Septembre 2020 09:44:19 
Objet: Re: [pve-devel] [PATCH v2 pve-container] POC : add/del/update ip from vnet-subnet-ipam 

On 08.09.20 05:52, Alexandre DERUMIER wrote: 
>>> When trying this I got the gateway IP returned for both, as CT IP and gateway IP. 
>>> Did not checked this patch closer, but I figured that this behavior is caused by 
>>> the SDN code. 
> 
> mmm, that's strange. 
> 
> When you create or update the subnet, the gateway ip you define on the subnet should be registered in the ipam. 
> (you have enable an ipam right ?) 

Yes, the built-in "PVE" one 

> 
> 
> Then, when you create CT, without any ip, it'll try to find first available ip in ipam. 

I did it on an existing CT, changing from a normal bridge to that vnet. 

> (So if the gateway was not registered in ipam (bug maybe), that could explain why you have it both). 
> 
> for internal ipam, i'm writing ipam database in /etc/pve/priv/ipam.db. (BTW,I'm not sure that it's the best path location) 

I'd like to have stuff in priv/ folder prefixed with a directory 
namespace, maybe "sdn" here. 

Besides that, how big can this get on huge setups? We only can have 512k files 
for now. 

> 
>>> On another node, do you think it makes sense to have vnets, subnets, IPam, DNS completely 
>>> split and separated from each other? I mean, it is flexible, but a user needs to do a lot 
>>> of, almost boilerplate-like, work to get this started. 
>>> Advanced users may profit from this, maybe we just need a "simple wizard" for the easiest 
>>> beginner case.. 
> 
> Well for subnet, you can assign multiple subnets by vnet, so yes, it's really need to by separated. 
> (Somebody at hertzner for example, buying subnets or /32 failovers ips, and want to add them to a vnet) 
> IPAM/DNS, are more reusable configurations. (like api url,key,....). So I think you'll define 1 or 2 of them max. 
> 
> I think subnet+ipam+dns are ip features. 
> zones,vnets,controller are physical network features 

Could it make sense to have subnets and vnets at least in the same section config, 
with different types? (a bit like storage.cfg) So that we reduce the configuration 
file amount a bit. 

Maybe we could also visualize this in the gui a bit "easier". 
We could merge VNet and SubNet management into one panel, maybe with split view 
like FW ipsets, you won't have the same subnet in different VNets after all, or? 

We could also merge DNS and IP management into one panel, maybe with split view 
like HA or vertical like FW ipsets. 

But this is not too relevant for now, can always be fine tuned once the API/backend 
stuff is in. 

On another note, are there some unit/regressions tests for this stuff? 
Would give a bit more confidence with this. 

skimming through the code currently, seems mostly OK for now, need to think a bit 
about how the general concepts are implemented and if that fits all OK. 


_______________________________________________ 
pve-devel mailing list 
pve-devel@lists.proxmox.com 
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel