Deployment solutions
A deployment solution is a named list of versioned clusters. Each row of the list may also name the shared database server that new tenants should use for that cluster. Picking a solution when creating a tenant fills the tenant's clusters in one step, instead of adding them one by one.
Deployment solutions are managed from the Clusters ▸ Solutions menu of Tenant Management. They require the same function as the tenants (TenantAdministration).
Why versioned clusters
A row references a cluster version (for example NeosCuisine - 0.0.1), not a cluster. The same cluster can therefore appear in several solutions with different versions. This is what lets you keep, side by side, a "Production" solution, a "Staging" solution and a "Canary" solution that differ only by the versions they deploy.
Properties
| Property | Description |
|---|---|
| Name | The unique name of the deployment solution. |
| Description | Optional free text. |
| Clusters | The rows of the solution: a cluster version and, optionally, a database. |
Each row has the following properties:
| Property | Description |
|---|---|
| Cluster | The cluster version taken by the tenants created from the solution. |
| Database | Optional. A shared database server of that cluster version. When empty, the administrator picks the database. |
Rules
The following rules are checked when a solution is saved:
- A solution holds at most one version per cluster. A tenant has at most one data location per cluster, so a solution with two versions of the same cluster could never be applied.
- The database of a row must belong to the cluster version of the row.
- The database of a row must be shared. A separate database receives a single tenant, so it cannot serve as a template for several tenants. A tenant that needs a separate database gets it during its creation, on the tenant's cluster row: proposed when it is the version's only free one, chosen by hand otherwise. The database lookup of a row only lists the shared databases of the row's cluster version.
A cluster version used by a deployment solution cannot be deleted. The error message names the solutions that use it.
A database server named on solution rows must stay shared: switching it to separate is refused. After a cluster version upgrade, update the database of the solution rows that named it.
Creating a tenant from a solution
On the Clusters step of the new tenant form, pick a deployment solution in the Deployed solution field, at the top of the clusters list. On an empty list, the clusters of the solution are added at once. When the list already holds clusters, a warning asks first: the clusters of the solution are added to the rows already there, which are kept, and No clears the field and adds nothing. The message shown afterwards names the clusters added; it is a warning when none was added.
Picking another solution afterwards asks whether to replace the list: Yes removes every row of the list, rows typed by hand included, and fills it with the clusters of the new solution. No puts the previous solution back in the field and leaves the list as it is. Clearing the field asks whether to empty the list: Yes removes every row of the list, rows typed by hand included, and the tenant is created without a solution; No puts the solution back and leaves the list as it is.
When the list is filled, one cluster row is added per row of the solution, with its exact version, and with its database when the solution row has one. When the solution row has no database, one is proposed: the version's single shared database or, when the version has no shared database, its single separate database not yet assigned to a tenant (the cluster row is then set to separate). Otherwise the database stays empty, and the message lists the rows whose database the administrator picks by hand. The isolation of a row follows the database proposed only: without one, an empty row already in the grid keeps the isolation set by hand, so the database can then be picked with that isolation. A manual pick of the version in the grid only proposes the single shared database. Clusters that are already in the grid are left as they are, and the message lists them.
The tenant remembers the chosen solution in its DeployedSolutionId property.
The tenant's solution
The deployment solution of a tenant is shown in its own box at the top of the Clusters panel of the tenant form (the field on the left, the description of the solution next to it), and as a column and a filter of the tenant list.
Once a tenant is saved with a solution, the field is read-only. A tenant without a solution (for example one created before deployment solutions existed) keeps an editable field until it is saved with one. Picking a solution on such a tenant without any cluster adds the clusters of the solution to the list at once. On a tenant that already has clusters, picking a solution only sets the field: no confirmation is asked and no cluster is added until Add the solution's clusters is clicked. Clearing the field removes no cluster.
Add the solution's clusters, at the right of the solution box, adds to the list the clusters of the solution that the tenant lacks, after a confirmation when the list already holds clusters, with the same database proposal as at creation. The clusters already on the tenant stay as they are, at their own version: the message lists them, and the rows left without a database. The changes apply when the tenant is saved, and the cluster rows not yet saved are shown in bold. The button is disabled while the tenant has no solution. In the tenant form, clusters are only ever added: only clearing or replacing the solution while creating a tenant removes rows.
The solution is a template and a label, not a contract:
- Saving a tenant does not compare its clusters with its solution: only Add the solution's clusters adds the missing ones.
- Changing a solution does not change the tenants created from it.
- The clusters of a tenant may drift from its solution (an upgraded cluster, an added or removed cluster). Nothing compares them.
Deleting a solution keeps its tenants and their clusters; the tenants only lose the link. When tenants are attached to the solution, a confirmation shows how many.
Not to be confused with commercial solutions
License Management has commercial solutions, which group the products sold to a customer. Deployment solutions are unrelated: they describe what is deployed for a tenant, not what was sold. There is no link between the two.