Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect handling of errors in IPAM #39

Open
gdearment opened this issue May 14, 2018 · 1 comment
Open

Incorrect handling of errors in IPAM #39

gdearment opened this issue May 14, 2018 · 1 comment

Comments

@gdearment
Copy link

The error handling in the IPAM add command is such that it is very hard to understand why something is failing. I've run into two problems that are due to the same general issue:

  1. The allocateClient doesn't differentiate between an interface already being maxed out on allowed IPv4 or IPv6 IP addresses and all IP addresses in a subnet being taken. Only the later is represented in the error here
  2. The error message from AllocateClient.AllocateIPFirstAvailableAtIndex(...) is clobbered unless there is more than one subnet that is tagged. This happens here.

For [2], if you have a single subnet for allocating Pod ENIs into, and the ENI is already attached to the host but has reached its maximum number of IPs, the error that will get returned is unable to create a new elastic network interface due to No subnets are available which haven't already been used but this is incorrect.

@theatrus
Copy link
Contributor

Thanks for the report @gdearment ! I agree, this could use some improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants