Fix nil pointer dereference in subnet validation #3150
Conversation
bennerv
added
bug
bennerv
requested review from
jewzaam,
hawkowl,
rogbas,
petrkotas,
jharrington22,
cblecker,
facchettos,
cadenmarchese,
UlrichSchlueter,
s-amann,
SudoBrendan,
Shivkumar13,
yjst2012,
anshulvermapatel and
hlipsig
as code owners
| if err = validateSubnetSize(s, address); err != nil { | ||
| return err | ||
| } |
There was a problem hiding this comment.
If this is validating a range, do we want to error if any element of the slice doesn't validate?
There was a problem hiding this comment.
Honestly I'm not sure.
I'm not even sure how openshift will handle this. You can technically specify multiple IP address ranges on a subnet now (wasn't that the point of a subnet to begin with!??).
For now, we've only seen customers with a single one defined. You have to opt into the MSFT AFEC feature flag Microsoft.Network/AllowMultipleAddressPrefixesOnSubnet in order to use it for now.
There was a problem hiding this comment.
I'm not even sure how openshift will handle this. You can technically specify multiple IP address ranges on a subnet now (wasn't that the point of a subnet to begin with!??).
For now, we've only seen customers with a single one defined. You have to opt into the MSFT AFEC feature flag Microsoft.Network/AllowMultipleAddressPrefixesOnSubnet in order to use it for now.
I poked around in the installer code and nothing I found indicated that the installer will be unhappy if you provide a subnet with multiple address ranges. Complicated stuff though, so it would be good to ask the installer folks to verify.
If OCP doesn't support multiple address ranges, we can error out here if the cx has put more than one and then the original question in this thread is moot.
There was a problem hiding this comment.
Thanks for the investigation.
I also poked around in machine-config-provider-azure and there is never an explicit subnet address assignment used during NIC provisioning, so it should be handled transparently. The only thing that is specified during creation is the subnet ID.
So I think the proper validation here would be to add up all the address spaces and make sure the total address space is >27 mask, also taking into account the number of reserved IP addresses in smaller address spaces may have an impact.
There was a problem hiding this comment.
It's not perfect, but instead of adding up individual ranges, I'm going to validate that at least one address prefix has a /27 or greater and error out if not.
If we have a bunch of /30s it's not going to make sense as there isn't enough address space for anything there. The cases around this are going to get crazy, and at least we're returning a valid message to the customer.
…refix is not in a subnet
This should allow us to catch any issues with using one over the other, since both are valid configurations on both vnets and subnets in Azure.
bennerv
force-pushed
the
fix-nil-pointer-dereference-in-dynamic
branch
from
d50f4d1
to
27a8c91
Compare
| wantErr: fmt.Sprintf("400: InvalidLinkedVNet: %s: The provided subnet '%s' is invalid: must be /27 or larger.", subnetPath, subnetId), | ||
| }, | ||
| { | ||
| name: "subnet size is gucci gang", |
Which issue this PR addresses:
Fixes a nil pointer dereference in cluster creation due to addressPrefix not being set during cluster creation.
What this PR does / why we need it:
Switch between addressPrefix and addressPrefixes on subnets.
Test plan for issue:
e2e & green ci
Is there any documentation that needs to be updated for this PR?
nope