Why we need the enable-service-topology config option?

[ialidzhikov]

#17929 added a TopologyAwareHints (topology-aware traffic routing) feature implementation for cilium.
However this feature put behind the config option enable-service-topology and it is disabled by default. Hence, a cluster admin has to enable it explicitly for cilium.
So the question we raised internally is: what is the benefit of this enable-service-topology config option? For making a Service topology-aware, the Service has to be annotated with service.kubernetes.io/topology-aware-hints=auto. So, the question is what is the benefit of enable-service-topology when the feature is already configurable per Service basis.
For comparison, on kube-proxy side the feature is behind the feature gate TopologyAwareHints and it is enabled by default since K8s 1.24. The feature gate will be removed after it is GA. Hence, the feature on kube-proxy side is enabled by default and in the future it won't be possible to disable it.

[ialidzhikov]

/cc @aojea @robscott

[ialidzhikov]

/cc @brb

[aojea]

it seems this was answered here during the review https://github.com/cilium/cilium/pull/17929/files#r753157675, it makes sense to start disabled by default on alpha features

[ScheererJ]

The initial reasoning for setting it to disabled per default makes sense. Meanwhile, some time has passed and the kubernetes feature moved to beta (enabled by default). Should this then also be applied to cilium or has this a different lifecycle? In other words: When could we expect this option to be GA/enabled by default?

[github-actions]

This issue has been automatically marked as stale because it has not
had recent activity. It will be closed if no further activity occurs.

[github-actions]

This issue has not seen any activity since it was marked stale.
Closing.