Error updating to 2019.1.2

[egimbernat]

When executing the update script as the Readme says, the following error occurs:

ERROR: (gcloud.deployment-manager.deployments.update) Error in Operation [operation-1565805098608-5901768b0a757-625aede9-254e678a]: errors:
- code: NO_METHOD_TO_UPDATE_FIELD
  message: No method found to update field 'timeout' on resource 'teamcity-waiter-software'
    of type 'runtimeconfig.v1beta1.waiter'. The resource may need to be recreated
    with the new field.

[rcm-bor]

The same error occurs when updating to version 2019.1.3, using the gcloud command:

gcloud deployment-manager deployments update teamcity2 --template https://raw.githubusercontent.com/JetBrains/teamcity-google-template/master/teamcity.jinja --properties zone:europe-west3-b,version:'2019.1.3'

[martinasia]

What works for me was copying the same command which I initially used to launch the deployment and replaced the 'create' with 'update'. Here's the difference between the two (create and update) :

CREATE Deployment :
$ gcloud deployment-manager deployments create <deploymentName> \ --template https://raw.githubusercontent.com/JetBrains/teamcity-google-template/master/teamcity.jinja \ --properties zone:<zone>,ipAddress:<ipAddress>,network:<network-name>,subnetwork:<subnetname>,domainName:<domainName>,domainOwnerEmail:<domainOwnerEmail>

UPDATE Deployment :
$ gcloud deployment-manager deployments update <deploymentName> \ --template https://raw.githubusercontent.com/JetBrains/teamcity-google-template/master/teamcity.jinja \ --properties zone:<zone>,ipAddress:<ipAddress>,network:<network-name>,subnetwork:<subnetname>,domainName:<domainName>,domainOwnerEmail:<domainOwnerEmail>,version:'2019.1.2'

[egimbernat]

Yes, in fact, does the update, unfortunately, in my case, the installation stopped working. Due to a conflict in the space needed for the Docker containers update. I had to run a fresh install with more storage and migrate the old server.

[wuservices]

I can confirm that the tip from @martinasia allows the update command to work, but like @egimbernat, the update broke my installation. After resetting the VM, I get a certificate error because nginx is running, but not TeamCity. I have a basically empty and new instance, so I think the process is just flawed.

However, you can also revert to 2019.1.1 then reset for things to come back.

@egimbernat when you say fresh install, are you still using the template, or did you set up a vm manually? How'd you migrate the old server?

[egimbernat]

@wuservices the process was divided into two steps:

1- Modify https://github.com/JetBrains/teamcity-google-template/blob/master/virtual-machine.jinja#L33 to allow more space. And execute again
2- Follow the guide at https://www.jetbrains.com/help/teamcity/creating-backup-from-teamcity-web-ui.html. In fact, they are two options, the full backup and restore of the directories (Rather than the backup on the UI) is preferable if you want to restore as much as the information, artifacts, and information you have.

I found easy to recreate all the deployment than try to fix the damaged instance, but I realized later, that some of the steps that the Jinja does can be reproduced on the damaged instance. Mainly they are to increase the disk storage capacity and stop all the services After that run the TeamCity service, let it finish and run nginx.

In a short resume, the problem of the update is that Docker doesn't found enough space to download the new image and silently fails. You can somewhat easy see it on the team city service journal.

[wuservices]

Thanks for these tips! It looks like the disk size in https://github.com/JetBrains/teamcity-google-template/blob/master/virtual-machine.jinja#L33 is for the data disk, not the vm / main server disk, which I think is the one we need more space on.

I was putting off working on the upgrade before, but today my instance ran out of space and went to 0 bytes on its own on the server disk for some reason. This forced me to start playing around. I resized the vm / server disk in the console to 12 GB (although I think 10 GB might be OK), then I reset the instance for the new space to be usable automatically. You can ignore the advice the console gives that you have to do repartitioning. This got me up and running again, but I decided to try the update again and it worked smoothly.

It sounds like the permanent solution here should be #5.