This document describes how to move all configurations, users, and groups from an organization to a newly created one.
Start by extracting all of the configurations per tenant. For each tenant, execute the following command:
tctl get all --tenant <tenant> > config.yaml
Once you have all the configurations in
config.yaml, make sure to manually copy the
various bindings (e.g. ApplicationAccessBindings, APIAccessBindings, etc) in it to a file called
bindings.yaml, and remove them from
This is due to the fact that when you use the contents of
config.yaml later, the fully qualified names for the
bindings will not exist, which would have resulted in an error when applying the configuration. The bindings will have
to be applied after the objects have been moved to the new organization.
You will also have to edit
config.yaml and replace the value in each
metadata.organization field in the file to
point to the new organization you will create.
If you are creating a new tenant, you should also change the tenant section.
Below is a sample YAML file showing what an entry in your
config.yaml should look like. Please also note that the YAML
file below does not have the fully qualified names,
resourceVersion. These should also be removed from
displayName: Bookinfo app
displayName: Bookinfo app
Apply the configuration
config.yaml has been edited, you need to create the new organization. Create a file called
myorg.yaml with the
following content, replacing the name with your new organization name:
Then apply the new configuration to create the organization.
tctl apply -f myorg.yaml
For each tenant in your old organization, you will have to create an equivalent tenant in the new organization. Create a file containing the necessary tenants. The content should look like the sample below, with the organization and tenant name replaced to valid values in your environment.
Then apply the new configuration to create the new tenant(s). The example assumes you have listed all of the necessary
tenants in the file
tctl apply -f mytenants.yaml
Finally, apply the configuration stored in the file
config.yaml you edited earlier:
tctl apply -f config.yaml
At this point, both the old and the new organizations will exist, but only the old one will be working, as you have not yet updated the configuration in the management plane to point to the new organization.
Onboard the clusters
Create a file
clusters.yaml with content resembling below sample, with the name of the cluster and organization
replaced to valid values in your environment. Add more entries for all of the clusters that should belong to the new
displayName: "Cluster T1"
Then apply the configuration. This will associate the clusters with the new organization.
tctl apply -f clusters.yaml
Create a file
controlplane.yaml resembling below sample, with the name of the cluster replaced to a valid value in
Sync the users/groups
At this point you should have all of the clusters and the control plane migrated to the new organization. You now need to synchronize the users and groups to the new organization. To do this, create a Job as follows
kubectl create job --from=cronjob/teamsync teamsync -n tsb
After some time, when the job is finished, you will be able to see the users and groups in the new organization from the TSB UI.
Make sure to remove
tetrate-agents from the bindings. Remove the section shown below from every binding in
- role: rbac/envreader
- team: organizations/<myorg>/teams/tetrate-agents
Then, after this is done, apply the bindings:
tctl apply -f bindings.yaml
Migrate the organization
At this point you have moved everything to the new organization, but the management plane is still configured to use the old one.
Create a file called
managementplane.yaml and point it to use the new organization:
Now is a good time to make sure you have not misconfigured anything, as applying this configuration may result in your applications being disconnected and taken down.
Make sure that you have no missing configuration from the old organization which has not yet been applied to the newly created organization. For example, when/if you have tier1-tier2 configured, you need to explicitly allow the network to communicate from tier1 to tier2.
Once you are satisfied, apply the new configurations:
kubectl apply -f managementplane.yaml
And finally, login to TSB using the new organization:
Once you have verified everything is working appropriately, you can proceed to delete the old workspaces, tenants, and organization.
In case you have an external LDAP configured to work with TSB, and users are still being validated against the old organization, you will need to manually fix data stored in Postgres. If you have followed the steps in the exact sequence as provided in this document, this should however not occur.
If you do need to fix Postgres, please make sure to backup the database first. When ready, issue the following
command from the Postgres command line, replacing
<your_old_org> with the name of your old organization:
delete from node where name like '%<your_old_org>%';
This will delete the required table, and also delete other related data from other tables via foreign keys.