Uh oh!
There was an error while loading. Please reload this page.
Adding a check for subnet pool overlap - #2148
Conversation
5688e3d to
ae3b701Comparectelfer
commented
May 10, 2018
Seems to cause TestIpamReleaseOnNetDriverFailures to fail. Was this intended? Also, another very naive Q without knowing the code: this seems to check whether a particular subnet was previously allocated by looking up said subnet in a map. Does this mean it will fail to detect overlap when there is partial overlap? For example net1 = 10.1.0.0/16 and net2 = 10.1.1.0/24? |
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
ctelfer
commented
May 10, 2018
Disregard the test cases query. Looks like you already fixed it. :) 👍 |
abhi
commented
May 10, 2018
The map only holds the keys. If there is partial overlap, key should ideally be different. In that case the next condition should verify the overlap case. |
codecov-io
commented
May 10, 2018
Codecov Report
@@ Coverage Diff @@## master #2148 +/- ##
=========================================
Coverage ? 40.46% =========================================
Files ? 139 Lines ? 22494 Branches ? 0 =========================================
Hits ? 9103 Misses ? 12052 Partials ? 1339
Continue to review full report at Codecov.
|
selansen
commented
May 11, 2018
LGTM |
ctelfer
commented
May 11, 2018
Ah, thanks. Should have read the rest of the code. 👍 |
euanh
commented
May 23, 2018
@abhi This pull request changes the semantics of |
selansen
commented
May 23, 2018
My Earlier understanding was we do support IP pool overlap for overlay network but not for bridge network which is technically correct. But now discussion concluded this will lead into issues and there is no customer use case for that. I had a discussion yesterday with @mark-church on this. We are planning we will stop network creation itself when customer tries to create network with overlapping network like the way we do for bridge networks. Currently when we create network, until there is a service gets created on the network we don't allocate subnet address for the network. But if the user sends subnet range while creating network, we shall compare it with existing subnet and reject them while creating network . We shall discuss in detail in upcoming meeting. |
selansen
commented
May 23, 2018
I tested Abhi's fix . Even though We get debug Error message , swarm stills creates network. I will look into how Bridge networks throws error and stops network creation and see if I can fix for overlay network instead of waiting for service creation to throw error. Driver type is missing in the network ls output. Looks like its still broken. docker@ELANGO-CE18-2-ubuntu-0:~$ docker network ls May 23 14:53:13 ELANGO-CE18-2-ubuntu-0 dockerd[17147]: time="2018-05-23T14:53:13.204622267-07:00" level=debug msg="Failed allocation of unallocated network z1g3d4bricg5gtinveth1roey" error="failed allocating pools and gateway IP for network z1g3d4bricg5gtinveth1roey: Pool overlaps with other one on this address space" module=node node.id=m6c9lto0r3o0eo9uy848z9nuk docker@ELANGO-CE18-2-ubuntu-0: |
euanh
commented
May 24, 2018
@selansen Ok. I'm working on a unit test for overlapping network allocations. |
abhi
commented
Jun 18, 2018
@euanh I will not be adding a design document for a bug fix. The semantics is not honored anywhere else in the repository. It just leads to misleading conventions that ppl end up using not knowing what really happens. @fcrisciani I think we need to this for 18.03 bp ? |
fcrisciani
commented
Jun 18, 2018
@abhi yep would be great to have |
euanh
commented
Jun 19, 2018
@abhi 👍 I wasn't asking for a design doc for a bug fix, just for a reference or explanation of the changes being made. Your edited PR description makes everything clear, in case we wonder in future why this change was made. :) |
MilosQL
commented
May 19, 2021
This check makes no sense for macvlan networks. #2334 |
ShyLionTjmn
commented
Sep 27, 2022
Please, address #2334 |
A part of the ipam library allows to use same subnets for 2 different networks. However this is not honored elsewhere in the whole library and leads to inconsistent behavior. The semantic is not honored for overlapping subnets as well. The request for overlapping subnets is rejected.
This change ensures that semantics are kept consistent by rejecting requests for an already allocated pool as well. So users will not be able to create networks with already allocated subnet/overlapping subnet