-
Notifications
You must be signed in to change notification settings - Fork 119
Description
User Story
As a user when I deploy CAPM3 with Metal3-IPAM, I encounter two types of IP claims: ipclaims.ipam.metal3.io and ipclaims.ipam.cluster.x-k8s.io, and two types of IP addresses: ipaddresses.ipam.metal3.io and ipaddresses.ipam.cluster.x-k8s.io. As a user, I find it confusing that there are two resources with the same name.
As a developer I want the code base I am maintaining to be simple as possible. Currently handling these two slightly different CRDs add un necessary complexity and I want to simplify this.
Detailed Description
As CAPI IPAM contract support is added there should be e2e test related to it. Metal3-ipam now supports CAPI IPAddress and IPAddresClaim CRDs so one thing we should try first is moving to use them completely while using IPPools provided by Metal3.
- This way we can test if it's possible to deprecate IPClaim and IPAdress from metal3-ipam
- We could also test if other IPAMProviders work with CAPM3
- This would simplify the code as well as only one CRD would be supported for IPAM instead of the current two. (Current
ipclaims.ipam.metal3.ioandipclaims.ipam.cluster.x-k8s.io, and two types of IP addresses:paddresses.ipam.metal3.ioandipaddresses.ipam.cluster.x-k8s.io.)
My suggestion for deprecating the redundant CRDs from IPAM: metal3-io/ip-address-manager#971
/kind feature
TASKS
- Add e2e-tests that use CAPI's
IPAddressandIPAddressClaimand Metal3-IPPools - Deprecate
fromIPPool - Add conversion function to switch Metal3
IPClaimsto CAPIIPAddressesClaimsin existing deployments. (Possible good idea to use preAllocations)- Same conversion for Metal3
IPAddressesto CAPIIPAddresses. This might come "for free" during upgrade. I don't think IPAddresses are moved but recreated.
- Same conversion for Metal3