Inherit VRF from parent prefix when reserving IP addresses

[anguswilliams]

IpAddressClaim previously created IP addresses with no VRF set, so they didn't show up nested under a parent prefix that has a non-global VRF in NetBox. NetBox's available-ips response already carries the prefix's VRF; thread it through into the WritableIPAddress sent on create, and preserve the existing VRF on update since it's a full PUT.

[anguswilliams]

Hey @jstudler I noticed you were taking a look at #515 so tagging you in here, apologies if you're not the right person.

I have an issue where VRF is set on a prefix in my netbox instance, the operator will find an available IP in that prefix (first prefix matching the specified CIDR), but then creates the IP in the global VRF (default when VRF is set to nil) which means the newly created IP has no parent prefix. This change fixes this to set the VRF to match the prefix it found when creating the new IP, which is the correct behaviour, as you can only guarantee the IP is available on the matched prefix.

This is only half the story however as the default behaviour is just to find grab the first prefix matched by the given CIDR, which won't work if the same cidr was used over multiple VRFs. I do wonder if #515 is a better approach but a bigger change, I only noticed it after adding this MR. Just gauging your interest in merging either of these? Happy to pickup MR 515 and rebase if you would prefer that approach.

[jstudler]

Hey @anguswilliams
Thanks for bringing up this issue. We didn't run into this bug because we didn't use VRF in our use cases.
We agree that this needs fixing so parent prefixes that use VRF should be able to be selected from IPAM Claim CRs. The best way would be to add the vrf field to the spec of the Prefix, IpAddress and IpRange CRDs so it's reflecting the NetBox API. If empty, the default value provided should default to the NetBox default value. In the PrefixClaim, IpAddressClaim and IpRangeClaim, we propose no changes in the CRD and to look up the VRF from the parent prefix and write it to the non claim resource spec. In the case of PrefixClaim, the user can specify the VRF in the parentPrefixSelector. The introduced changes should of course be non-breaking for existing scenarios and e2e tests.
In short, we are in favor of an approach more similarly to #515
We would appreciate your contribution.