Promote ServiceExternalIP to beta #6903
Conversation
| @@ -209,7 +210,7 @@ var ( | |||
| Multicast: {Default: true, PreRelease: featuregate.Beta}, | |||
| Multicluster: {Default: false, PreRelease: featuregate.Alpha}, | |||
| SecondaryNetwork: {Default: false, PreRelease: featuregate.Alpha}, | |||
| ServiceExternalIP: {Default: false, PreRelease: featuregate.Alpha}, | |||
| ServiceExternalIP: {Default: true, PreRelease: featuregate.Beta}, | |||
There was a problem hiding this comment.
Need to update the value of ServiceExternalIP feature in the antrea-agent.conf and antrea-controller.conf, and regenerate manitests
xliuxu
force-pushed
the
xliuxu/promote-service-external-ip
branch
2 times, most recently
from
0e44ad4 to
ba3daf2
Compare
Fixes: antrea-io#6743 Signed-off-by: Xu Liu <[email protected]>
xliuxu
force-pushed
the
xliuxu/promote-service-external-ip
branch
from
ba3daf2 to
0043100
Compare
| As MetalLB will allocate external IPs for all Services of type LoadBalancer, | ||
| once it is running, the Service external IP management feature of Antrea should | ||
| not be enabled to avoid conflicts with MetalLB. You can deploy Antrea with the | ||
| default configuration (in which the `ServiceExternalIP` feature gate of | ||
| ServiceExternalIP feature disabled (in which the `ServiceExternalIP` feature gate of |
There was a problem hiding this comment.
The phrasing is a bit strange. I would expect users to be able to keep using MetalLB with Antrea without having to make any specific configuration change, even after we graduate the feature to Beta.
My understanding is that despite the above warning about "conflicts with MetalLB", as long as the Services are not annotated with service.antrea.io/external-ip-pool, Antrea will not try to allocate LB IPs for the Services and there will be no conflict. However, the "check" kind of happens late IMO, which means we are doing work for nothing and some logs may create confusion for users:
antrea/pkg/controller/serviceexternalip/controller.go
Lines 501 to 502 in afb9dfc
I'd like to hear @tnqn's opinion on this. Do we feel like the annotation is enough to "gate" that feature once the FeatureGate itself is promoted to Beta (keep in mind that the long term goal after promoting a feature to Beta should to go to GA, at which point the FeatureGate stops being available altogether in theory). Or do we need a boolean configuration parameter, as a way to explicitly enable / disable the feature (as we have done in other places). Typically we do not need the boolean when the feature is API-driven, but this case is slightly different.
Fixes: #6743