Consider moving IPAM provider out of experimental

[vincepri]

• What are the requirements for this provider to move to v1beta1 types / guarantees?
• Are there long standing issues?
• What would be the next logical step from the current state?

cc @schrej

[vincepri]

/triage accepted

[vincepri]

/cc @rvanderp3 @JoelSpeed

[sbueringer]

Just to confirm. You're only talking about dropping the feature gate on the IPAM types + moving them to v1beta1, right?

(there is no IPAM provider in core CAPI)

[vincepri]

Yes

[fabriziopandini]

I will defer this to the folks working on IPAM/to the majority on the community meeting, however, if I'm not wrong we just merged a couple of changes on IPAM API types, so might be worth giving some more room to gather feedback from the field before graduation (might be it will be enough doing it in 1.6 instead of 1.5)

[schrej]

I'd say the requirements are that the API doesn't require any breaking changes anymore. There are a few additive changes that are in discussion, e.g. #8424 or an optional hostname field, but we haven't found anything else so far.

There is some significant use by VMware Tanzu, which lead to heavy development on the in-cluster provider and all of it's requirements (with the exception of the mentioned Conditions field) should be met. (cc @tylerschultz @srm09)

With providers that integrate with external solutions there might be requirements we aren't aware of yet, which would be an argument to remain experimental. Unless we consider in-cluster ipam as the minimum feature set, and further additions (like hostnames and conditions) as optional. The latter would make it a bit more cumbersome to mix and match ipam and infra providers.

[schrej]

/area ipam

[sbueringer]

I'd say the requirements are that the API doesn't require any breaking changes anymore.

Absolutely up to you, but I think it's good enough if we think it's reasonable stable and fulfills the use cases we currently want to address. As we're only talking about v1beta and not v1 (I think), we have some leeway mid- to long-term to make breaking changes if actually necessary.

[tylerschultz]

We at VMware agree with @schrej. Aside from discussion around potentially adding the Conditions field (an additive change), we don't see anything that needs to change. Like Jakob says, perhaps more will be learned as other providers come on line. We have no strong opinion either way on moving out of experimental.

[rvanderp3]

Hi all, I'm following up on this discussion to see if anything has been learned that would prevent the IPAM APIs from being promoted to v1beta1. Thanks!

[rvanderp3]

@tylerschultz @schrej following up here to see if there are any new thoughts around the possibility of promoting the API to v1beta1. I'm happy to help with the promotion if needed.

[schrej]

I'd say we can go ahead and promote to beta. It's been quite a long time and we haven't found anything else. As said, we might need something for hostnames, but that would be additive, which is fine.

[killianmuldoon]

If folks are happy to move forward with this it would be good to announce it at the community meeting. The code freeze for the next release is Tuesday 14th November 2023, so there's probably enough time to get a v1beta1 set of APIs prepared and merged. If anyone's interested in taking up the work feel free to assign yourself.

[rvanderp3]

sure, we can discuss at the next meeting. I'll go ahead and assign it to myself for now unless anyone else wants to grab it.

/assign @rvanderp3

[rvanderp3]

Per the discussion in the meeting today, will create v1beta1 for the IPAM types in the exp package.