Reseller Support Without Requiring Separate Keystone Domains

Summary
Enable the creation of reseller accounts within the default domain, avoiding the need to create and manage separate Keystone domains for each reseller.

Background
In our current understanding of OSIE’s tenancy model, resellers are implemented by creating a dedicated OpenStack Keystone domain, with customer projects created within that domain.

While this provides a logical separation between resellers, it introduces additional operational overhead and complexity.

Current Behaviour

  • Creating a reseller requires provisioning a new Keystone domain

  • Each domain operates with isolated identity management

  • Shared resources such as images, flavours, and networking constructs require additional configuration to be made accessible across domains

  • This leads to:

    • Duplication of configuration

    • Increased administrative overhead

    • Risk of inconsistency between domains

If this functionality already exists or can be achieved through an alternative design, we would appreciate any documentation or guidance on recommended best practices.

Problem
For service providers operating a multi-tenant platform, the requirement to create separate domains per reseller introduces unnecessary complexity when:

  • The underlying infrastructure (compute, storage, networking) is shared

  • Standardised offerings (flavours, images, policies) are centrally managed

  • Operational consistency across all customers is required

Managing multiple domains makes it harder to:

  • Maintain a single catalogue of images and flavours

  • Apply consistent policy and governance

  • Streamline onboarding and automation workflows

Desired Behaviour
Allow resellers to be created within the default domain, using constructs such as:

  • Project hierarchy (nested projects / parent-child relationships)

  • RBAC and role-based delegation

  • Scoped administrative permissions per reseller

This would allow:

  • Logical separation of resellers

  • Delegated control to reseller administrators

  • Continued use of centrally managed shared resources (images, flavours, etc.)

Example Workflow

  • A reseller is created as a top-level project (or organisational unit) within the default domain

  • Customer projects are created beneath the reseller

  • The reseller is granted administrative permissions scoped only to their projects

  • Shared resources remain centrally managed and accessible without duplication

Benefits

  • Reduced operational overhead

  • Simplified resource management

  • Consistent service catalogue across all tenants

  • Easier automation and onboarding

  • Improved scalability of the platform



  • Thanks!

Please authenticate to join the conversation.

Upvoters
Status

In Review

Board

πŸ› Issues

Date

11 days ago

Author

Kevin.Pannell

Subscribe to post

Get notified by email when there are changes.