The eventgate chart has been refactored to support canary releases. Along the way, we stopped using the release name to differentiate the different app deployments of eventgate. Instead, we now use main_app.name. We should switch back to the convention of calling the production release of an app 'production', and also add a 'canary' release with a single replica.
[x] eventgate-logging-external is not yet in use, so that can happen without any client disruption.
eventgate-analytics and eventgate-main are in use. For those we'll need to deploy the new production and canary releases alongside the 'analytics' and 'main' releases. To avoid port conflict, we'll have to pick new nodePorts for the 'production' release's Service. Once the new releases are deployed, we'll have to switch LVS to use the new ports.
eventgate-main will change ports from http 32192 and https 4292 to http 34192 and https 4492.
eventgate-analytics will change ports from http 31192 and https 4192 to http 35192 and https 4592.
[x] Deploy canary and production releases for eventgate-main in all clusters on nodePorts 34192 and 4492
[x] Deploy canary and production releases for eventgate-analytics in all clusters on nodePorts 35192 and 4592
[] Create new LVS services for eventgate-analytics on ports 34192 and 4492 and eventgate-main on ports 35192 and 4592 - https://gerrit.wikimedia.org/r/c/operations/puppet/+/572960
[] Point clients (MediaWiki EventBus, refinery oozie swift upload, sparql query updater) to new LVS service ports
[] Remove old LVS services on old ports
[] Destroy eventgate-main 'main' and eventgate-analytics 'analytics' Helm releases.
[] Remove eventgate-main 'main' and eventgate-analytics 'analytics' Helm
release configs from services helmfile.yaml files.