jkoelker / quark

This is my fork, Quark is now at https://github.com/rackerlabs/quark
Apache License 2.0
0 stars 2 forks source link

Policy checking is busted somehow #169

Closed MattDietz closed 10 years ago

MattDietz commented 10 years ago

Was able to create a subnet with one IP possible IP:

| 7037deef-0631-419a-8021-d8053fc31d41 | | 192.168.0.0/30 | {"start": "192.168.0.2", "end": "192.168.0.2"} |

The code seems to acknowledge that there should only be one IP in that subnet, but it keeps generating new ones somehow:

fixed_ips | {"subnet_id": "7037deef-0631-419a-8021-d8053fc31d41", "ip_address": "192.168.0.7"} |

Previous iterations generated 0.6 and 0.5 in testing.

asadoughi commented 10 years ago

I'm not able to reproduce with latest quark. I wrote another test in krauq based off of TestSubnetAllocationPools.test_create_subnet_v4_allocation_pools and it produced a NeutronError when I tried to create a second port.

MattDietz commented 10 years ago

It might be in the code we're working on, then. I just wanted to make sure we don't forget about it.

On Fri, Sep 27, 2013 at 12:58 PM, Amir Sadoughi notifications@github.comwrote:

I'm not able to reproduce with latest quark. I wrote another test in krauq based off of TestSubnetAllocationPools.test_create_subnet_v4_allocation_pools and it produced a NeutronError when I tried to create a second port.

— Reply to this email directly or view it on GitHubhttps://github.com/jkoelker/quark/issues/169#issuecomment-25264328 .

MattDietz commented 10 years ago

Repro: create a small subnet. 0.0.0.0/29 is handy because there are only 5 viable addresses in the subnet.

Create enough ports until an exception is triggered

Delete a port

Immediately create a new port: an IP will be allocated, and past the end of the subnet boundary to boot

MattDietz commented 10 years ago

Figured it out. If you keep deleting ports, you can add one new port for each deleted. In short, the allocation count check succeeds because there's theoretically space in the subnet, but the IPs aren't yet available. We fail to reallocate any IPs from said subnet, but then it's returned as a viable candidate for generating a new IP and nothing checks to see that it's within the CIDR. Fixes include a final check for CIDR viability plus potentially reorganizing the db code to not select subnets with some deallocated but not yet reallocatable IPs in the first place.