During the codfw kubernetes upgrade (T397148), thumbor was not depooled by the cookbook (as it does not have a discovery entry in service catalog). Depooling it would not have helped though, since we hardcode codfw thumbor in the swift config:
hieradata/codfw/profile/swift/proxy.yaml:profile::swift::proxy::thumborhost: 'thumbor.svc.codfw.wmnet:8800' hieradata/codfw/profile/swift/proxy.yaml:profile::swift::proxy::inactivedc_thumborhost: 'thumbor.svc.eqiad.wmnet:8800'
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | JMeybohm | T341984 Update Kubernetes clusters to 1.31 | |||
| Resolved | Raine | T397148 Update wikikube codfw to kubernetes 1.31 | |||
| Open | None | T397618 Fix thumbor discovery records and make swift use them |
Change #1164457 had a related patch set uploaded (by Hnowlan; author: Hnowlan):
[operations/dns@master] wmnet: add discovery records for thumbor
Change #1164458 had a related patch set uploaded (by Hnowlan; author: Hnowlan):
[operations/puppet@production] service: add discovery active/active config
@JMeybohm @Clement_Goubert this sounds like something we may need to do before next Kubernetes upgrade (or at least surfacing it so you know about that special case).
In case there's capacity to do it this quarter, please move it to Scheduled
Tagging Data-Persistence so we can get opinions on if/how we actually *can* make swift fail over to another thumbor when we need to or not.