Fusion 2.5 to Fusion 3.3
These instructions should work for 2.5 to 3.3 but have not been tested.
Upgrading will remove the following resources:
adf-fusion- No longer used by Fusion. To preserve any custom work, remove the resource from the state file.app-historyuploadrequest- Replaced by app-fusion-ui, fd, and plan-fusion-uiapp-models,func-databroker,sqldb-models- Replaced by storing the model in ADX with new functions for querying it.appConfig- No longer used by Fusion. To preserve any custom configuration, remove the resource from the state file.appi-elevate- Elevate services now log to appi-fusion. To preserve existing logs, export them or remove the resource from the state file.func-starsync- StarSync functionality is now handled by func-tagcontroller.func-telemetry-NEWSends Elevate service logs and metrics to App Insights.
Additionally, the following storage account containers will be removed:
bulk-history-parquets,model-input- Model data and parquet files are now uploaded via the IoT hub and stored in the "uploads" container (before ingestion by ADX).ignition- No longer used by Fusion. To preserve any content, download it or remove the container from the state file.model-input-history- No longer used by Fusion. To preserve any content, download it or remove the container from the state file.pi-event-frames- No longer used by Fusion. Event frame data is uploaded via the IoT hub and stored in ADX.
The following instructions must be preformed to upgrade Fusion 2.5 to Fusion 3.1. The terraform commands migrate and remove resources from the terraform state file that have been modified for the release.
It is recommended, but not strictly required, to wait for any history upload requests to finish before upgrading. I.e., wait for any requests with an end time to have uploaded all of their data.
pre_install: This variable is used to determine which resources need to be refreshed in the state file before the upgrade lock: This variable is used to enable/disable locks on resources during the upgrade process
- If upgrading a "dev" environment and preserving SQL Server is desired, set
"tagControllerDevSqlServer = true"within the consumer module of the main.tf file. - Remove ADF: in the resource group overview, select the ADF (adf-fusion-*) resource and delete it.
terraform refresh -var pre_install=trueterraform state mv "module.consumer.azurerm_sql_database.sqldbTagController[0]" "module.consumer.azurerm_sql_database.sqldbTagController[\"tagcontroller-companyname-environment`"]"` (Elevate deployments only)terraform import -var pre_install=true module.consumer.azurerm_service_plan.appServicePlan /subscriptions/subscription-Id/resourceGroups/resource-group-name/providers/Microsoft.Web/serverfarms/app-service-plan-nameterraform state rm module.consumer.azurerm_app_service_plan.appServicePlan
If in 2.5 Post Deployment steps an event hub consumer group was created for ehub-dpp and named "adx", then this must be imported into the state file; run the following command:
terraform import -var pre_install=true "module.consumer.azurerm_eventhub_consumer_group.eventHubAdxDppConsumerGroup" "/subscriptions/subscription-Id/resourceGroups/resource-group-name/providers/Microsoft.EventHub/namespaces/eventhub-namespace/eventhubs/ehub-dpp/consumerGroups/adx"
Otherwise, delete the event hub consumer group that was created in the 2.5 Post Deployment steps. This deletion is an optional clean-up step.
If in 2.5 Post Deployment steps an ADX database data connection was created and named "adx-connection", then this must be imported into the state file; run the following command:
terraform import -var pre_install=true "module.consumer.azurerm_kusto_eventhub_data_connection.adxConnection" "/subscriptions/subscription-Id/resourceGroups/resource-group-name/providers/Microsoft.Kusto/Clusters/adx-cluster-name/Databases/adx-database-name/DataConnections/adx-connection"
Otherwise, delete the ADX database data connection that was created in the 2.5 Post Deployment steps. It's name could be anything, but it's Source is ehub-dpp. Failing to delete this connection will result in duplicate data being pushed into ADX.
- If upgrading an Elevate system, to prevent data loss, stop all Elevate services.
- In ADX, wait for any current ingestion to finish and then run the fusion3.2_pre-install.kql script.
terraform apply -var lock=falseterraform apply- If func-tagcontroller is backed by a SQL Server database, upgrade the sqldb-tagcontroller database.
- If the CurrentValue table needs to be migrated, run the fusion3.2_post-install.kql script.
Post Upgrade
In the SQL database, sqldb-tagcontroller:
- This database has changed significantly and migration of existing upload requests and tag states is not easy. Whether the requests are kept or not, any data currently being collected will continue to be collected. To preserve existing upload requests and tag states, see Preserve Upload Requests and Tag States and then proceed with the next step. If it is not necessary to keep these, then the existing data can be deleted with the following SQL commands. Note that all tags will then be in the "NoData" state, so any future run of StarSync will cause new requests to be made with these tags and some amount of duplicate data – one to five days, probably, depending on StarSync configuration – to be uploaded.
DROP TABLE UploadContent
DROP TABLE EventRequest
DROP TABLE HistoryUploadRequest
DROP TABLE TagMap
DELETE FROM __EFMigrationsHistory
- Delete the following users:
- the Fusion admin group
- the Fusion read/write group
- the Fusion read-only group
- the application registration (e.g., fusioncompanyname-environment)