Skip to content

Multi-tenant Org Transition Planning

This page is for administrators of multi-tenant clusters or shared installations.

Support for multiple Orgs and the benefits will be available to all clusters after all of the transition stages are complete.

This page provides guidance for manual steps accompanying the software release upgrades until the Customers hierarchy become Orgs.

Transition plan⚓︎

For an overview, see Transition stages.

Hydrolix upgrades and background software build connections between users, credentials, storage definitions, and other objects and the new Customer objects. These changes are automatic and auditable before the Customer object hierarchy replaces the original as new Org.

The software automatically assigns relationships according to current project definitions and user permissions.

At each of the transition stages, administrators can correct or change the associations so that the Customer objects accurately reflect tenants before the new hierarchy and associated objects are put into use.

Each release includes

  • safety checks that must succeed before any upgrade
  • audit tooling

Release specific instructions⚓︎

These instructions are specific to multi-tenant clusters.

Upgrade to v6.1⚓︎

For the Hydrolix v6.1 upgrade, set tunable turbine_api_feature_migrate_projects_to_orgs=true to create a Customer object for each project, which later becomes an Org.

This step begins the creation of Customer objects. See parallel hierarchy.

This is only the first of the steps.

Result⚓︎

At the completion of all transition stages, a multi-tenant cluster will have:

  • one Org for each project
  • a new Org for the administrative hydro project
  • a new Org for the read-only sample_project project
  • all Users are associated with their primary Org
    • a non super_admin User can be a member of multiple Orgs
  • Credential and Storage objects exist outside the hierarchy
    • if an object doesn't belong to an Org, only super_admins can administer it
    • objects belonging to an Org can only be edited by Users in that Org with sufficient permissions: belongs_to
    • objects linked to and used by an Org, can be used by that org