|9 Jan 2024
|i double checked the certs on the zk servers with openssl and both the client and server cert have expirations in feb. the ca cert expires in 2030
|looks like that one is coming from https://gerrit.googlesource.com/zuul/ops/+/master/k8s/zookeeper/zookeeper.yaml#3
| there's a liveness probe that connects over ssl and runs
ruok ever few seconds, and that appears to be working
|which suggests that the zk cluster is able to accept ssl connections in general (and specifically with its copy of the client cert)
|however, that is a different certificate than the executor is using
|they both have approx the same expiration dates
|i wonder if zk is caching an old copy of the certs and needs to be restarted
|i'm inclined to restart zk then restart zuul.
|okay, after the initial restart of zookeeper-0, it did not join the quorum because of cert errors, but after restarting all 3, they have reformed a quorum. i think that lends credence to the "stale cert" theory.
|I see an executor in the components list now
|it looks like all the zuul components have automatically reconnected; so the actual fix for this was "restart zk"
|zuul is working through a backlog of fairly old data
|i think we can declare it back in service; we should fix that pod disruption thing tho; i wonder if that has something to do with why the cert upgrade wasn't handled.
|Clark: nasser_linaro fyi, i'm using kubectl with the google cloud auth setup to get the logs and run commands; i don't think i've ever had access to logs in the web console. in case you want to see about setting up the same.
|ok, I don't thjink I ever had access to the google cloud stuff or k8s there
|You can't view tags if you can't view any branches with the tagged commits.
|10 Jan 2024
|Hi, ran into an another issue after
|stnma7e_27446 joined the room.
| I could view all branches in that repo, but I'm guessing that some tags were created, some branches were deleted (maybe, no idea if that's actually the case) and since the branch didn't exist I couldn't see the tags.
The thing that really bug us, is why the other admin could see them
|I would guess you have slightly different permissions if another user could see them and you couldn't
|12 Jan 2024
| For the 3.7 upgrade, the labels approval copying fields are removed (I have at least
copyAllScoresIfNoCodeChange). The release notes mentions a schema migration exists and it seems to be https://gerrit-review.googlesource.com/c/gerrit/+/334325 . Does that implies that on upgrade gerrit init will magically update the settings in all projects? I guess I can just try it 😄
|Yes, I think that happens in an init step
|I guess I have to give it a try and validate the copy condition matches my expectations 🙂
|thanks nasser_linaro !
In reply to @_discord_450041161265184789:t2bot.iosince the new syntax was also supported in 3.6, the approach we took was to load all our configs into a test deployment of 3.6, upgrade it to 3.7, check what the upgrade process did to the configs, applied those changes to another 3.6 test deployment, upgraded that to make sure it resulted in no changes, then applied that new configuration to our 3.6 production site
|and also introduced some new rules in our config linter to make sure no old-style configs got added in the lead-up to our production upgrade maintenance
|and double-checked after the production upgrade that there were no new changes to the configuration
|31 Jan 2024