This describes how to migrate a tedge-standalone installation which is connected to Cumulocity using BASIC AUTH (e.g. username/password) to a new tenant.
The migration script does the following steps:
- Backup the existing settings (tedge.toml and credentials.toml)
- Set the new tenant id in the credentials.toml file (used for basic auth)
- Set the new c8y.url to point to the new tenant
- Try reconnecting to the new tenant, then one of the following is done: a. If the new connection is successful, then delete the backed up files b. If the new connection is not successful, then rollback the settings, and then try to send the logs with info about the migration to the original Cumulocity tenant.
-
In the new tenant, register the same device credentials in a new tenant (The credentials MUST be kept the same).
This can be done using the Bulk Registration API, below shows an example of the go-c8y-cli command to register a device on the new tenant.
c8y deviceregistration register-basic --id "<external_id>" --password "<device_password>"
Note: The credentials should be kept the same to avoid having to send the credentials via the c8y_Command (shell) operation in clear text.
-
On the device, create a new file migrate-device.sh (the script contents are within the same Github Gist) under the tedge/bin folder
For example, if tedge in installed under
/data, then you would create the following file (using vi):vi /data/tedge/bin/migrate-device.sh
Then make the file executable
chmod +x /data/tedge/bin/migrate-device.sh
-
Then you can create a Cumulocity shell operation to execute the command
migrate-device.sh "<new_c8y_url>" "<new_c8y_tenant_id>"
Where,
<new_c8y_url>is the Cumulocity URL (without thehttps://prefix) of the new tenant<new_c8y_tenant_id>is the Cumulocity Tenant ID of the new tenant
Example
migrate-device.sh mytenant.example.cumulocity.com t12345
Notes
- The c8y_Command (shell) operation will be set to SUCCESSFUL before the migration is done. The operation status is meant to only indicate that the migration activity was successfully started. This is done because the device will be switching to a new tenant, so if the migration wouldn't be done in the background, then the operation status would never be updated as the switch to the new tenant would be completed before the status is reported back.
- Check the device's event page (in the original tenant) for events to indicate when the migration has started, and in the event of an error, there will be an event with a log file that you can use for debugging.