Error upgrading from 16.11.10 to 17.0.0

General
1

Hi, I’m facing this error upgrading from 16.11.10 ee to 17.0.0 ee:

Running handlers:
[2024-11-22T14:34:42+01:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:

version_file[Create version file for Gitlab KAS] (gitlab-kas::enable line 67) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/gitlab-kas --version` failed with a non-zero exit code (2)
stdout: 
stderr: panic: failed to parse "2024-05-15T09:09:49+0000" into RFC3339 compliant time object, because: parsing time "2024-05-15T09:09:49+0000" as "2006-01-02T15:04:05Z07:00": cannot parse "+0000" as "Z07:00". Fix the build process.

goroutine 1 [running]:
gitlab.com/gitlab-org/cluster-integration/gitlab-agent/v17/cmd.init.0()
        /var/cache/omnibus/src/gitlab-kas/cmd/build_info.go:18 +0xf3


Running handlers complete
[2024-11-22T14:34:42+01:00] ERROR: Exception handlers complete
Infra Phase failed. 13 resources updated in 23 seconds
[2024-11-22T14:34:42+01:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2024-11-22T14:34:42+01:00] FATAL: ---------------------------------------------------------------------------------------
[2024-11-22T14:34:42+01:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2024-11-22T14:34:42+01:00] FATAL: ---------------------------------------------------------------------------------------
[2024-11-22T14:34:42+01:00] FATAL: RuntimeError: version_file[Create version file for Gitlab KAS] (gitlab-kas::enable line 67) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/gitlab-kas --version` failed with a non-zero exit code (2)
stdout: 
stderr: panic: failed to parse "2024-05-15T09:09:49+0000" into RFC3339 compliant time object, because: parsing time "2024-05-15T09:09:49+0000" as "2006-01-02T15:04:05Z07:00": cannot parse "+0000" as "Z07:00". Fix the build process.

goroutine 1 [running]:
gitlab.com/gitlab-org/cluster-integration/gitlab-agent/v17/cmd.init.0()
        /var/cache/omnibus/src/gitlab-kas/cmd/build_info.go:18 +0xf3


===
There was an error running gitlab-ctl reconfigure. Please check the output above for more
details.
===
warning: %posttrans(gitlab-ee-17.0.0-ee.0.el7.x86_64) scriptlet failed, exit status 1
Non-fatal POSTTRANS scriptlet failure in rpm package gitlab-ee-17.0.0-ee.0.el7.x86_64
  Verifying  : gitlab-ee-17.0.0-ee.0.el7.x86_64                                                                                                                         1/2 
  Verifying  : gitlab-ee-16.11.10-ee.0.el7.x86_64                                                                                                                       2/2 

Updated:
  gitlab-ee.x86_64 0:17.0.0-ee.0.el7                                                                                                                                        

Complete!

anyone could help fixing this?
Best regards,
Alessandro

2
3

Thanks @dnsmichi ! If I upgrade directly to 17.0.1 it should work or am I in need to upgrade to 17.0.0 before go to 17.0.1? My goal is to upgrade to the latest stable release of gitlab and then export/import data on a new server running Debian 12.
Best regards,
Alessandro

4

@alessandro75 the problem occurs in 17.0.0, so if you want to upgrade to 17.0.0 you would need to edit /etc/gitlab/gitlab.rb and add/change the following line to disable kas:

gitlab_kas[‘enable’] = false

then run gitlab-ctl reconfigure to disable it and upgrade to 17.0.0. I don’t use KAS so have it disabled anyway, but some people may use it with Kubernetes, so may require it to be enabled. The above was explained in the link @dnsmichi replied with.

The current upgrade path from 16.11.10 quotes the path as follows:

16.11.10 → 17.3.7 → 17.5.2 → 17.6.0

therefore you do not need to upgrade to any 17.0.x release as such, you can start with 17.3.7 which includes the fix that was made to address the kas error you got when upgrading to 17.0.0. Of course, after each upgrade wait until background migrations have completed before starting the next one, else you can break your install.

Also make sure you have a backup before you upgrade.

1 Like
5

Hi @iwalker , so, if I have correctly understud, I do not need to upgrade “step by step” till I get 17.6.0 but I can do some “jump”, in detail: 16.11.10 to 17.3.7 to 17.5.2 to 17.6.0 is it correct?
Thank you very much for your support!
Best regards,
Alessandro

6

Yes, correct. They are the versions that you need to go through as there will be certain DB migrations at those points that need to be applied.

If you want, you can do every single point release but you would be looking at hundreds of upgrades doing it that way and extremely time-consuming. This is why the upgrade path is there to follow and minimise that.

7

Thank you very much @iwalker I’ll go this way!

1 Like