Feature: Strict allocations in Network.get_next_network()

[nickpegg]

In Network.get_next_network(), we currently do what @jathanism has coined as a "loose" allocation. For example:

1. 10.1.2.0/24 is in the DB as allocated
2. 10.1.2.0/25 is also in the DB as allocated
3. When get_next_network() is called on 10.1.2.0/24 (the parent) for a prefix length of /32, an address within 10.1.2.0/25 is offered

However, there's a use case where we'd want to request a "strict" allocation, meaning that 10.1.2.0/25 is considered off-limits and the above call to get_next_network() would instead consider an address from 10.1.2.128/25 since it doesn't exist in the database.

[rmhasan]

Hi @nickpegg, your not stating that you want a special flag for a network when you are allocating it right? You want to change the behavior of get_next_network so that when you call get_next_network() on a network, you wont get a network inside one of its child networks that are allocated. You will get a network that is outside of any allocated child network.

[rmhasan]

This also happens for prefix lens between 25 and 32 exclusive.

[rmhasan]

@nickpegg Looking at the code in get_next_network(). If we have a generator subnets = (s for s in subnets if s not in dirty) and we set next_subnet to next(subnets), I don't think we need to check immediately right after if next_subnet is in dirty. So I plan on getting rid of the following if statement that comes directly after next_subnet = next(subnets).

if next_subnet in dirty:
    continue

[rmhasan]

Hi @nickpegg and @jathanism, I have a implementation of get_next_network() in the works. My implementation is more simple than the current implementation. It also addresses the issue of strict allocation. I plan on making a PR soon, I just need to do more testing. I have a question. Lets say you have the three following networks for a site.

10.2.1.0/24
10.2.1.0/25
10.2.1.192/27

Add you want to execute the command nsot networks list -s 2 -c 10.1.2.0/24 next_network -p 26 -n 3 would you want 10.2.1.128/26 to be listed. It is the parent of 10.2.1.192/27.

[rmhasan]

Hi @nickpegg and @jathanism, I opened a pull request for this, lets take the conversation over to #256.

[jathanism]

@rmhasan Hey, thanks for submitting this. We'll take a look!

I haven't looked at your pull request yet, but the comment you made about getting rid of the if next_subnet in dirty check is an important one for optimizing speed of the lookup algorithm to reduce unnecessary iterations.

[jathanism]

Fixed in #256