Custom Query (13 matches)

Current allocation structure is a little too limiting, need to expand it to support deeper suballocation structures

Allow merging arbitrary sets of contiguous allocations plus free blocks to create new allocations or allocation trees. The most common use case will likely be extending an allocation into adjacent free space, or merging adjacent allocations given to the same customer, but several other actions are supported:

• Extend a container so that previously adjacent leaf or container allocations are now children
• Extend a container across adjacent allocations, deleting only immediate peer allocations but keeping all suballocations
• Extend a container across adjacent allocations, deleting all allocations involved except those within the original allocation
• Extend a container across adjacent allocations, deleting all suballocations within the new allocation
• Merge a group of leaf allocations into a single leaf allocation

Also supports type conversion, preserving data or deleting it much as above depending on the original and target types. Keeping existing data when converting to IP pools will result in all IPs in the existing allocations being flagged as "used" and filled with the information from the original allocation. Converting from an IP pool to a container type creates /32 allocations for each IP.

In case of an allocation for a customer who may require more address space in the near future, and would like to keep that address space contiguous, allow a flag to be set on the original allocation (and the resulting free space blocks) that the free space immediately after the original allocation should be reserved to allow for this expansion.

Needs to have a method to manually return this reserved space to the free pool in case of running low on available free blocks.

Related to #8, and peripherally #7.