Deleting VNets in script #309
|
I'm writing a script that deletes vnets. I'm trying to figure out what, if any, API calls I need to make to IPAM when deleting a vnet that was created with an IPAM reservation, in order for the CIDR to become available for a new reservation. It looks like reservations become 'fulfilled' (or 'settled') once a vnet is created using that CIDR. If I then delete that vnet, the settled reservation still exists - will that prevent the CIDR from being reissued? The vnet itself shows up in red and as 'ErrNotFound' in the UI - do I need to do an API call to delete it completely? If I do have to make API calls to delete either the reservation or the network in this situation, do I really have to know the Block id to do so? It seems like if I know the reservation ID, I should be able to delete it without knowing what block it belongs to. It also doesn't appear that I can easily query the reservation by its ID alone? So would I have to get a list of all reservations in the space and filter it, if I know the Space name and the Reservation ID but not which block it might have been assigned to? (All of this may be moot if deleting the actual vnet has already returned the cidr range to circulation, which a previous thread I was reading through suggests may be the case) |
Replies: 2 comments 11 replies
|
Hey @timothycrall, allow me to explain some of these items you mentioned a bit further.... From a Reservation perspective, until a Reservation is "fulfilled" or "cancelled", the CIDR assigned to that Reservation will affect availability of future CIDR requests, meaning that the tool will not assign a CIDR that overlaps a Reservation that is in a non-fulfilled/non-cancelled state. Once the Reservation becomes fulfilled/cancelled, that CIDR is no longer blocked by the Reservation process (which leads to the next item). When a Virtual Network is associated to a Block, the CIDR space of that Virtual Network affects the availability of future CIDR requests, meaning that the tool will not assign a CIDR that overlaps a currently associated Virtual Networks address space. Once a Virtual Network is either deleted within Azure, or un-associated with a Block, that CIDR will become available for assignment once again. Here an abbreviated list of the order of the checks that happen when requesting a new CIDR:
To directly answer your question from above of what API calls that you need to worry about in order to free a CIDR space, the answer is simply to call the DELETE API to remove the Virtual Network association from the target Block. Technically, once you delete the Virtual Network from Azure then the tool will no longer see the CIDR as used, however the UI will mark that stale entry as "ErrNotFound" because the association to the Virtual Network ID is still there because the current behavior doesn't auto-remove these entries when the Virtual Network is no longer detected (this is changing shortly). Here is the API I was referring to above:
So I know that was a lot, and I'm sure you'll have additional questions. Please know that I'm here to support you whatever you many need, and if you'd prefer to have a live conversation simply shoot me an email at Matthew.Garrett@microsoft.com and we can go through everything in real time. |
|
Yes, but you should know which Space/Block during requests as these relationships are hierarchical with the tool. A Virtual Network could be associated with multiple Blocks because in Azure you can assign multiple Address Spaces, and each of these Address Spaces may be linked to a different Block as there is no Azure requirement to make those contiguous. Hope that makes sense! Happy to help you envision different way to accomplish this more effectively. |
|
It does make sense (although we're never assigning more than one address space to a vnet in our architecture). My use case is that I have a Space with three Blocks associated with it. For new vnets that I'm creating with IPAM, I can tag the vnet when I create it with its Block. But for existing VNETs that have been associated into the Block (by checking their box in the UI), if I receive a request to delete one, I don't know what Block it's associated with (although I suppose I could compare its Address Space to the three blocks and determine it that way). |
|
Would be kind of nice to be able to just give the vnet resource ID to the API and say "delete all block associates connected to this vnet" |
|
This is a great point and a fair ask. I'll add this to my short-term roadmap right now. |
|
Of course, once you've implemented the "delete vnets after they've been removed from Azure for a period of time", my need for that feature will probably be negated, as the easiest way to handle it will be to just delete the vnet and let IPAM catch up. Can I just say, this is by far the fastest and most helpful support I've ever received from a github project or from Microsoft support in general. Thanks! |
|
@DCMattyG has this feature been implemented in the meantime? Documented limitations are ambiguous imho. |
|
Hey there donk-msft, before I answer your question I'd like to make sure we're talking about the same product. This GitHub repo is for the open-source Azure IPAM platform whereas the link you provided about is for the IPAM feature of Azure Virtual Network Manager, which is completely separate from this and is a 1st party offering from Azure. Is your question around the open source project or AVNM IPAM Pools? |
Hi @DCMattyG my apologies, I was looking at both solutions and apparently mixed them up. I was talking about AVNM, not the open source project. Thank you for your quick response. |
Hey @timothycrall, allow me to explain some of these items you mentioned a bit further....
From a Reservation perspective, until a Reservation is "fulfilled" or "cancelled", the CIDR assigned to that Reservation will affect availability of future CIDR requests, meaning that the tool will not assign a CIDR that overlaps a Reservation that is in a non-fulfilled/non-cancelled state. Once the Reservation becomes fulfilled/cancelled, that CIDR is no longer blocked by the Reservation process (which leads to the next item).
When a Virtual Network is associated to a Block, the CIDR space of that Virtual Network affects the availability of future CIDR requests, meaning that the tool will not assig…