Feature Request: Ability to configure the pool with a list of non-contiguous IP addresses about cluster-api-ipam-provider-in-cluster HOT 6 CLOSED

Sorry, somehow missed this one. Sounds reasonable, go for it!

from cluster-api-ipam-provider-in-cluster.

The allocation behaviour is fixed now.

from cluster-api-ipam-provider-in-cluster.

FYI - We've found an environment where we can obtain blocks of contiguous IPs, so we're delaying our work on this. We'd still like to contribute it, but it has fallen in priority for us.

from cluster-api-ipam-provider-in-cluster.

If this feature request is reasonable/acceptable to the powers that be, we would like to contribute the implementation.
Is more discussion needed?

from cluster-api-ipam-provider-in-cluster.

Hi @schrej, we think we found an inconsistency in the behavior of First and Last.

Suppose the pool spec were to look something like this:

spec:
  prefix: 24
  subnet: 10.0.0.0/24

First and Last would be defaulted to 10.0.0.1 and 10.0.0.254.
The FindFreeAddress function calls .Next() on the first IP in the range and the first ip provided would be 10.0.0.2. This seems good, the gateway is typically the 10.0.0.1.
Side note: it could be another address in the range. (citation needed)
The last address (10.0.0.254) would never be provided because the guard prevents the last address from being provided. We assume the intention was not to provide the 255 address, but we aren't sure.

Next lets consider when the user specifies First and Last:

spec:
  prefix: 24
  subnet: 10.0.0.0/24
  first: 10.0.0.10
  last: 10.0.0.15

First and last would not be defaulted and would stay as specified.
The FindFreeAddress() function would first try First.Next() resulting 10.0.0.11. The code would never return 10.0.0.15 because of the guard that prevents the last address from being provided.

We propose that we change the logic so that the First and Last be provided. The only exceptions being that First or Last was the network address (10.0.0.0), the gateway address (10.0.0.1 or whatever was provided), or the broadcast address (10.0.0.255). This would be a significant change in the behavior, so we'd like to hear if you think this would be problematic. Hopefully that makes sense.

from cluster-api-ipam-provider-in-cluster.

Calling First.Next() in FindFreeAddress is just a implementation mistake. I think I didn't have first and last in the beginning and was just using the Subnet, which would be Subnet().From().Next() in that function, which would be correct if you want to skip the network address. It should also hand out the To Address, so that's a mistake as well. Not sure how to handle this properly though. Maybe we can just add a check there to see if To is used. Otherwise we need to compare whether we've passed To, and the complexity for that might not be worth it just to have a cleaner loop.
The gateway isn't handed out already, since it's part of the existing IPSet that's passed to FindFreeAddress.

In summary: First and Last should always be used. Gateway should be excluded. If the user messes up and sets the network address as First, that's on them, same for broadcast. If the user just sets a subnet, defaulting takes care of excluding the first and last address of that subnet.

from cluster-api-ipam-provider-in-cluster.