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 v2 pve-container] POC : add/del/update ip from vnet-subnet-ipam
Date: Tue, 8 Sep 2020 10:58:53 +0200 (CEST)	[thread overview]
Message-ID: <1179667870.443488.1599555533057.JavaMail.zimbra@odiso.com> (raw)
In-Reply-To: <65ed6f59-a12b-c331-4b65-a9e95afda377@proxmox.com>

>>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. 




  reply	other threads:[~2020-09-08  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24 16:49 Alexandre Derumier
2020-09-07 16:40 ` Thomas Lamprecht
2020-09-08  3:52   ` Alexandre DERUMIER
2020-09-08  7:44     ` Thomas Lamprecht
2020-09-08  8:58       ` Alexandre DERUMIER [this message]
2020-09-11  2:27         ` Alexandre DERUMIER
2020-09-24  8:58           ` 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=1179667870.443488.1599555533057.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