Block munging - "merge blocks"

[Kris Deugau]

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.

[Kris Deugau]

(In [717]) /trunk

Begin committing "merge/extend blocks". See #8.

This commit adds the first merge page to the UI.

[Kris Deugau]

(In [719]) /trunk

Scope options on emerge page weren't up to date. 'clearall' needed
to be relabelled, and the label it had needed the correct underlying
option ('clearpeer').
See #8.

[Kris Deugau]

(In [720]) /trunk

Second page in merge sequence; show main allocations and free blocks
that would be affected by the merge, along with reminders as
appropriate about data that may be lost with the combination of merge
scope and target type selected for the new allocation.
See #8.

[Kris Deugau]

(In [725]) /trunk

Add utility sub _poolToAllocations() to support complex block merges,
and type-mapping hash %poolmap to map pool IP types to the "right" type
of allocation. See #8.

[Kris Deugau]

(In [727]) /trunk

Refine variable passing and template variable names on merge prep pages
for accuracy and clarity. See #8.

[Kris Deugau]

(In [728]) /trunk

Stub out major logic branches for mergeBlocks(), and flesh out some prep
operations. See #8.

[Kris Deugau]

(In [729]) /trunk

Stub out subbranches of first major branch in mergeBlocks(). Fix up
some mispasted bits. See #8.

[Kris Deugau]

(In [730]) /trunk

Fill in first mergeBlocks() working segment: Merge to container, keep
all allocations. See #8

[Kris Deugau]

(In [731]) /trunk

Fill in second mergeBlocks() working segment: Merge to container, clear
mergeable allocations or clear all allocations. See #8

[Kris Deugau]

(In [732]) /trunk

Fill in next mergeBlocks() working segment: Merge to container, keep
suballocations, convert mergeable leaf blocks to free blocks. See #8.

[Kris Deugau]

(In [733]) /trunk

Cleanup while rechecking merge-to-container in UI:

• Move descriptive strings for merge scopes into a hash in IPDB.pm, so we don't have to update them everywhere every time they might change... now that most of the changes are done, of course.
• Refiddle listForMerge's freeblock branch to show only direct children, or all free blocks depending on another optional argument.
• Render previous point pointless due to dropping freeblocks from the return list of merged blocks anyway, because Confusion.
• Force scope as well as type when merging a master block. Merging any other type in a way that happens to intersect a master remains undefined.
• Make sure to capture the blocks merged/deleted for return.
• Fix up some variable names for consistency.
• Fix stupid typo missed in r732.

See #8.

[Kris Deugau]

(In [735]) /trunk

A little more surrounding cleanup:

• Tweak merge confirmation template to show the scope or not on different criteria for clarity.
• Remove call to retrieve free blocks for listing on the confirmation page.

See #8

[Kris Deugau]

(In [736]) /trunk

Add internal utility sub _toPool() needed for merge-to-pool. See #8.

[Kris Deugau]

(In [737]) /trunk

Fill in merge-to-pool. See #8.

[Kris Deugau]

(In [738]) /trunk

Fill in merge-to-leaf. See #8.

[Kris Deugau]

(In [744]) /trunk

Fill in first major block of rDNS for mergeBlocks(); new allocation is
a container. See #1 and #8.

[Kris Deugau]

(In [745]) /trunk

Add a flag to _toPool() to indicate whether to return all of the
allocations converted. Defaults to "off", but required so that rDNS
deletes can be called with the complete list of leaf blocks converted.
See #8.

[Kris Deugau]

(In [745]) /trunk

Add a flag to _toPool() to indicate whether to return all of the
allocations converted. Defaults to "off", but required so that rDNS
deletes can be called with the complete list of leaf blocks converted.
Also return type code of merged/returned blocks for further internal
processing.
See #8.

[Kris Deugau]

(In [746]) /trunk

• Tweak header docucomment for brief description of scope arguments for mergeBlocks()
• Adjust return data structure in mergeBlocks() to match and propagate the change in _toPool() in r745. This is needed for properly handling a couple of branches of reverse DNS RPC calls. See #8.

[Kris Deugau]

(In [747]) /trunk

Add first subbranch of "merge to pool" rDNS calls - keepall/mergepeer.
See #8.

[Kris Deugau]

(In [748]) /trunk

Fill in next major subbranch of mergeBlocks() rDNS calls;
clearpeer/clearall.
See #8.

[Kris Deugau]

(In [749]) /trunk

Commit last branch of rDNS call for mergeBlocks(); target == "leaf"
allocation.
See #8.

[Kris Deugau]

(In [751]) /trunk

Finally commit last stage of user-facing "merge blocks" process. See #8.

[Kris Deugau]

(In [752]) /trunk

Fine-tune original allocation UPDATE; make it into a prepared statement
and call that in locations downstream instead of copy-pasting calls.
Also add missing call in targettype==leaf branch. See #8.

[Kris Deugau]

Resolving this ticket as "Feature implemented"

[Kris Deugau]

(In [789]) /trunk

Add an ACL flag for merge operations. This is not automatically included
in the "Admin" priviledge per request, since a merge operation can
potentially wipe virtually the entire dataset. See #8.