We’ve found a potential issues with upgrades at customers. The sessionRequest container needs to perform some extensive data migration which is taking too long for some customers and hits a timeout. Currently we’ve only seen this in the appliance of Mark Plettenberg.
For 4.2 we’re going to apply a fix by increasing the timeout. We’re also investigating a better solution to this simultaneously but we’re not sure when that will be ready.
If an upgrade fails/hangs at a customer you can verify if this is the root cause by checking the health status of the sessionRequests container in “Container Status” page. It’ll show that there’s 1 or more pending migrations. The same can be found in the container log when you check out portainer. If this is the case you can workaround this issue like this:
1. Scale the session requests microservice to 0 (docker service scale VSI_sessionrequests=0)
2. Step into the sessionrequestDb container and execute the following script using psql one line at a time to keep track of the progress easier.
ALTER TABLE "SessionRequests"."SessionRequests" ADD "TestType" integer NOT NULL DEFAULT 1;
UPDATE "SessionRequests"."SessionRequests" SET "TestType"='2' WHERE "TestRunId" IS NOT NULL;
INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") VALUES ('20200128123613_Version41TestType', '3.1.2');
3. Scale the session requests microservice to 0 (docker service scale VSI_sessionrequests=1)
When customers use the external DB this is the script to be executed.
ALTER TABLE [SessionRequests].[SessionRequests] ADD [TestType] int NOT NULL DEFAULT 1;
GO
UPDATE "SessionRequests"."SessionRequests" SET "TestType"='2' WHERE "TestRunId" IS NOT NULL;
GO
INSERT INTO [__EFMigrationsHistory] ([MigrationId], [ProductVersion]) VALUES (N'20200128123613_Version41TestType', N'3.1.2');
Comments
0 comments
Please sign in to leave a comment.