Feature Request Overview (mandatory - Complete while in New status)

What user goal or problem do you need to solve?

In Red Hat OpenStack Services on OpenShift 18 deployments with custom Keystone endpoint configurations, the Octavia Operator currently hardcodes authentication to use the internal Keystone endpoint. This prevents successful Octavia installation when the internal endpoint is not available or when the deployment architecture requires using a custom/external Keystone endpoint.

The Octavia Operator needs the ability to specify custom authentication credentials and endpoint configurations to support diverse deployment architectures where the standard internal endpoint is not used.

Business justification (mandatory - Complete while in New status)

How would this feature benefit the customer?

This feature would enable customers to deploy Octavia in OpenStack environments with custom endpoint configurations, which is critical for:

1. Deployment Flexibility: Customers with specific network architectures or security requirements that mandate custom Keystone endpoints can successfully deploy Octavia without workarounds
2. Production Readiness: Eliminates a blocking issue preventing load-balancing-as-a-service capabilities in production environments with non-standard configurations
3. Security Compliance: Allows customers to maintain their required security posture by using designated authentication endpoints rather than being forced to expose internal endpoints
4. Architectural Consistency: Enables consistent endpoint management across all OpenStack services rather than requiring special cases for Octavia
5. Reduced Support Burden: Eliminates the need for complex workarounds or manual interventions during deployment

Without this feature, customers cannot utilize Octavia's load balancing capabilities in deployments where custom Keystone endpoints are required, forcing them to either compromise their architecture or forgo load balancing services entirely.

Functional requirements (mandatory - Complete while in New status)

What do you want the result of this feature to be? Add as many requirements as needed.

• FR1: Custom Authentication Secret Support - The Octavia Operator must support configuration of a custom Kubernetes secret containing authentication credentials (username, password, project, domain) that override the default internal endpoint credentials
• FR2: Custom Keystone Endpoint Configuration - The Octavia Operator must allow specification of a custom Keystone authentication endpoint URL through the Octavia CR (Custom Resource) or operator configuration
• FR3: Backward Compatibility - The implementation must maintain backward compatibility with existing deployments using internal endpoints; when no custom authentication is specified, the operator should default to current behavior
• FR4: Validation and Error Reporting - The operator must validate custom authentication credentials and endpoints during reconciliation and provide clear error messages if authentication fails, including which endpoint was attempted
• FR5: Documentation - Comprehensive documentation must be provided showing how to configure custom authentication secrets and endpoints for the Octavia Operator, including examples for common use cases
• FR6: Secret Reference in Octavia CR - Add a new field in the Octavia CR spec (e.g., keystoneAuthSecretRef) that allows referencing a custom secret for authentication rather than using the default secret
• FR7: Endpoint Override Configuration - Add configuration options in the Octavia CR to specify custom endpoints for Keystone authentication (e.g., keystoneAuthURL)

Describe the customer impact

IMPORTANT: Do not include customer names.

• Provide links to the account project: [Add your account project link here if available]
• Provide links to any related support tickets (open or closed):
  • https://access.redhat.com/support/cases/#/case/04285608 - Original support case documenting the authentication failure and recommendation to open this RFE
• Current Impact:
  • Customer is blocked from deploying Octavia in their Red Hat OpenStack Services on OpenShift 18 environment
  • Error: "error while setting the compute quotas: Authentication failed" during Octavia operator reconciliation
  • Root cause: Operator attempts to authenticate against internal Keystone endpoint which is unavailable in their deployment architecture
  • Customer requires custom Keystone endpoint for their production environment due to network architecture requirements
• Workaround Status: No viable workaround currently exists that maintains the customer's required architecture

(Optional) Point of contact

Provide any additional points of contact for this feature request, such as an account executive, SA, or TAM:

• [Add SA/TAM name and contact if applicable]
• [Add Account Executive if applicable]

(Optional) Additional links

[Use More > Link to add related issues such as:]

• Link to original support case: https://access.redhat.com/support/cases/#/case/04285608
• Any related documentation or architecture diagrams that illustrate the custom endpoint requirement

This RFE provides a comprehensive case for adding flexible authentication configuration to the Octavia Operator while maintaining backward compatibility with existing deployments.

Feature Overview (mandatory - Complete while in New status)
An elevator pitch (value statement) that describes the Feature in a clear, concise way. ie: Executive Summary of the user goal or problem that is being solved, why does this matter to the user? The “What & Why”... 
<your text here>

Goals (mandatory - Complete while in New status)
Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

• Who benefits from this Feature, and how? 
• What is the difference between today’s current state and a world with this Feature?
  <your text here>

Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

 
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…
<your text here>
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>
Out of Scope _ _(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>
Documentation Considerations _ _(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>
 
Questions to Answer _ _(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>
Background and Strategic Fit (Initial completion while in Refinement status):
Provide any additional context is needed to frame the feature.
<your text here>
Customer Considerations _ _(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>
Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

  Reviewed By	Team Name	Accepted	Notes