Parallel Hierarchy Installation

The Customer object was introduced in Hydrolix v6.1.

It's part of a sequence of transition stages over several Hydrolix releases to install support for multiple organizations.

Automatic changes⚓︎

After upgrade, a fully automatic background job creates Customers according to the tunable turbine_api_feature_migrate_projects_to_orgs.

No manual changes are required.

Manual changes⚓︎

Administrators can associate multiple projects with a single Customer for tenants using multiple projects. See Modify customer objects.

Upgrade instructions⚓︎

Visit Upgrade to v6.1 for step-by-step instructions.

Downgrade instructions⚓︎

Rollback warning: downgrading from v6.1 to an earlier release will cause all Customer objects to be deleted.

Before upgrading to v6.1 again, set the tunable according to your environment.

Reset with different tunable⚓︎

If you upgraded to v6.1 and didn't set the tunable correctly, either

downgrade to an earlier release and Upgrade to v6.1 again
use this manual process to avoid downgrade and upgrade

Manual transition instructions⚓︎

Use these instructions to change the turbine_api_feature_migrate_projects_to_orgs tunable while v6.1 is running without downgrading.

Switch tunable to create multiple customers⚓︎

Use these instructions if you want many Customer objects and you forgot to set tunable turbine_api_feature_migrate_projects_to_orgs to true.

Find the default customer ID.
Delete the customer object using DELETE /config/v1/customers/{id}.
Set tunable turbine_api_feature_migrate_projects_to_orgs to true.
Wait for init-turbine-api job to finish.
It will automatically create new customers for each project.

Switch tunable to create one customer⚓︎

Use these instructions if you accidentally set the tunable turbine_api_feature_migrate_projects_to_orgs to true.

Set tunable turbine_api_feature_migrate_projects_to_orgs to true.
Wait for init-turbine-api job to finish.
Delete all customer objects created from projects using DELETE /config/v1/customers/{id}.
All projects will be assigned to the default customer.

Background job behavior⚓︎

A continuously running background job creates Customer objects according to the following rules.

It always creates one Customer each for the hydro and sample_project projects.
If tunable is false (default), background job create_default_customer_projects creates a single Customer and associates projects.
If tunable is true, background job create_customers_from_projects creates a single Customer for each project and associates them.
Sets each Customer name to the name of its associated Project, when there's only one project.

Projects created after the upgrade, and while v6.1 is running, are also automatically assigned to a corresponding Customer object.

Modify customer objects⚓︎

Adminstrators may modify the Customer to Project associations.

The background job in v6.1 continuously manages Customer objects

Don't change the name of a Customer object until a later release, unless it is associated with multiple Projects.

The Config API introduced the Customer model in v6.1. These endpoints are transition tools to allow grouping of several Projects to a single Customer. This is useful for tenants with multple projects.

Accounts with sufficient permissions can use the endpoints to modify the association of projects to customers in v6.1.

Report orphaned projects⚓︎

A future cluster upgrade requires that there are no orphaned projects. For most scenarios, the background job accomplishes this.

To audit a cluster for any projects that lack a corresponding Customer object, use the following endpoint:

/config/v1/orgs/:org_id/projects?customer_id__isnull=True

A good response includes no projects.

While the cluster is running at v6.1, newly created projects may briefly show up in the results before the background job creates the corresponding Customer object.

A response with projects shows orphans. The orphans must be manually or automatically assigned to a Customer before a future upgrade.