Feature Request
Summary
Currently, the OCI Native Ingress Controller auto-generates names for OCI Load Balancer Listeners and Backend Sets using internal functions (GenerateListenerName and GenerateBackendSetName), producing opaque names like route_443 and bs_e38a715fdad0117. There is no supported annotation or configuration to override these names.
This is a feature request to introduce annotations that allow users to specify custom, human-readable names for these OCI LB resources.
Proposed Annotations
oci-native-ingress.oraclecloud.com/listener-name: "my-custom-listener"
oci-native-ingress.oraclecloud.com/backend-set-name: "my-custom-backendset"
Use Case
In enterprise environments with multiple OKE clusters or shared Load Balancers, OCI LB resource names surface in:
- OCI Console (Load Balancer → Listeners / Backend Sets)
- OCI Audit and access logs
- Cost reporting and tagging dashboards
- Incident response and RCA documentation
Auto-generated opaque names make it difficult to:
- Identify which Kubernetes workload owns a given LB resource
- Correlate OCI LB resources with application teams or environments
- Comply with organisational naming conventions or governance policies
Current Behaviour
- Listener name:
route_<port> (e.g. route_443)
- Backend Set name:
bs_<truncated_hash> (e.g. bs_e38a715fdad0117)
Both are hardcoded outputs of GenerateListenerName(servicePort) and GenerateBackendSetName(namespace, serviceName, port) in pkg/util.
Expected Behaviour
When the annotation is present, the controller uses the user-supplied name when creating or reconciling the OCI LB resource. When absent, existing auto-generation logic is preserved as fallback — fully backward-compatible.
Additional Notes
This would bring NIC in line with naming flexibility offered by other ingress controllers and cloud-native LB integrations, where custom resource naming is a standard operator concern.
Feature Request
Summary
Currently, the OCI Native Ingress Controller auto-generates names for OCI Load Balancer Listeners and Backend Sets using internal functions (
GenerateListenerNameandGenerateBackendSetName), producing opaque names likeroute_443andbs_e38a715fdad0117. There is no supported annotation or configuration to override these names.This is a feature request to introduce annotations that allow users to specify custom, human-readable names for these OCI LB resources.
Proposed Annotations
Use Case
In enterprise environments with multiple OKE clusters or shared Load Balancers, OCI LB resource names surface in:
Auto-generated opaque names make it difficult to:
Current Behaviour
route_<port>(e.g.route_443)bs_<truncated_hash>(e.g.bs_e38a715fdad0117)Both are hardcoded outputs of
GenerateListenerName(servicePort)andGenerateBackendSetName(namespace, serviceName, port)inpkg/util.Expected Behaviour
When the annotation is present, the controller uses the user-supplied name when creating or reconciling the OCI LB resource. When absent, existing auto-generation logic is preserved as fallback — fully backward-compatible.
Additional Notes
This would bring NIC in line with naming flexibility offered by other ingress controllers and cloud-native LB integrations, where custom resource naming is a standard operator concern.