Get Multiple Subnet CIDRs

[jkieffer0616]

I didn't see this in the discussion or docs anywhere but I'm wondering if there is a way to either reserve a subnet CIDR so the next time a call to the nextAvailableSubnet API is made it'll return a new CIDR or if I could pass a # of subnets to the API and it return that many available CIDRs.

Use case would be something like databricks where 2 subnets are required. Trying to automate this I would need to:

• Get CIDR from nextAvailableSubnet
• Pass the CIDR to terraform to create
• Once IPAM recognizes the creation, call the nextAvailableSubnet API again to get the latest available CIDR
• Pass that to terraform to create the subnet

If I could get 2 available CIDRs at once I could pass the array of CIDRs to terraform/ARM and create them in one step.

Hopefully that makes sense! Thanks!

[pschonfeld]

Unfortunately, I don't have a fix for you, but I have a similar issue, and this functionality would probably help: #213

[DCMattyG]

Hi @jkieffer0616 and @pschonfeld, I wanted to circle back here because I'm planning to implement this feature soon.

I agree with @pschonfeld that running this in a loop is a challenge, but for now I'd like to focus the on the initial item of providing a request for multiple subnets from within a single API call. Something like this...

[
    {
        "vnet_id": "<Virtual Network ID>",
        "size": 24
    },
    {
        "vnet_id": "<Virtual Network ID>",
        "size": 24
    },
    {
        "vnet_id": "<Virtual Network ID>",
        "size": 24
    }
]

I'd like to understand the expectations if one of the 3 requests were to fail, perhaps because there isn't enough available CIDR space within the Virtual Network to fulfill all 3 requests. My initial thought is to fail the entire API call, my reasoning is that this is really a single API call with multiple values, and an API either succeeds or it doesn't.

Thoughts on the format and/or desired failure behavior?

[pschonfeld]

I agree with a transaction-like mechanism where the entire batch fails if requests cannot be fulfilled (e.g., due to insufficient CIDR space). Regarding the failure behavior, I suggest returning detailed error information for each failed request rather than a generic error for the entire batch. This can help users understand and rectify specific issues.

[jkieffer0616]

Sorry I never got back on this. I agree with your approach on failing the entire call because it is a single API call and I also like @pschonfeld idea of returning the error of specifically which one failed. Looking forward to seeing it in action! Thanks!

[DCMattyG]

Got it! Thanks so much for the feedback, I'll get on this right away 👍

[aleksandr-morozov]

Hello @DCMattyG, do you have any updates on the feature implementation?

Apart from the many thanks for that functionality which will be very helpful, I also would like add my 50 cents in terms of potential cases in favor of reservation feature for subnets as well as we have for blocks.

In my case, our team has a responsibility on the vnet level (comparing described by you case when azure team gets the range by the network team and should get it sliced for vnets). So, we get one or several vnets per department and need to provide a mechanism for product teams to get the available subnet dynamically for their applications. Teams should be able to invoke nextAvailableSubnet API call from different places (pipelines) simultaneously which brings us to the issue described above since we don't have reservations. Array of available subnets as an output of API call doesn't solve that issue obviously. Does it make send to consider that functionality to be available in upcoming future?