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

Customers using Dell ECS (or any S3-compatible object storage exposing a Swift API) as their OpenStack object storage backend cannot fully manage object storage resources through Horizon. Specifically, Horizon requires selecting a Swift Storage Policy when creating buckets/containers, even when an external Swift-compatible backend does not use or expose Swift Storage Policies.
This prevents customers from performing all CRUD operations from Horizon and forces them to rely on alternative tools (Dell ECS WebUI or CLI), resulting in fragmented workflows and increased operational complexity.

Business justification (mandatory - Complete while in New status)
How would this feature benefit the customer?

• It enables customers using Dell ECS or other Swift-compatible object storage systems to manage buckets directly in Horizon without needing an OpenStack Swift cluster.

• It eliminates the operational overhead of running and maintaining both OpenStack Swift and an external object storage solution solely to satisfy Horizon’s UI requirements.

• It improves user experience by allowing a single, unified interface for object storage management, reducing training, context switching, and errors.

• It strengthens Red Hat OpenStack’s value proposition by supporting heterogeneous storage backends commonly used by enterprise customers who already rely on S3-compatible platforms.

• It enhances ecosystem flexibility and increases OpenStack adoption in environments where Swift is no longer the preferred or strategic object storage solution.

Functional requirements (mandatory - Complete while in New status)

• Horizon must allow bucket/container creation without requiring a Swift Storage Policy, when the backend object store is Swift-compatible but does not implement Swift policies (e.g., Dell ECS).

• Horizon must detect or allow configuration of non-Swift backends that expose the Swift API, avoiding Swift-specific validation that blocks CRUD operations.

• All bucket CRUD operations (create, list, delete) must be supported through the Horizon UI for Swift-compatible backends.

• Horizon should expose a configuration toggle that:

• • Disables mandatory Swift policy selection, or

• • Allows selecting “No policy / external backend,” or

• • Dynamically hides the policy selector if the backend does not provide policy listings.

• The Horizon UI should provide consistent error handling and messaging when interacting with Swift-compatible backends that do not support native Swift features.

Describe the customer impact

Because Horizon does not currently allow bucket creation without selecting a Swift Storage Policy, customers cannot use OpenStack’s primary management interface for object storage operations.
This bottleneck forces operational teams and end users to switch to external interfaces (Dell ECS UI, CLI, etc.) for basic tasks, causing:

• Increased complexity and inconsistent workflows

• Higher training overhead

• Risk of configuration drift

• Reduced usability of OpenStack for developers and tenants

• Requirement to deploy and maintain Swift only to satisfy UI limitations, even when the customer does not use Swift for object storage

This limitation leads to avoidable operational costs and reduces the overall value of Red Hat OpenStack in mixed-backend environments.

IMPORTANT: Do not include customer names.

• Provide links to the account project
• Provide links to any related support tickets (open or closed)

For details on connecting Jira issues to an account, see Connecting Jira Issues to Accounts.

(Optional) Point of contact

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

(Optional) Additional links

Click More > Link to add any links to issues, such as an outcome, that are related to this feature request.

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