[02:55:01] <wikibugs>	 10serviceops, 10Core Platform Team, 10MediaWiki-Cache, 10Performance-Team (Radar): Ensure apcu incr/decr are atomic (Upgrade php-apcu) - https://phabricator.wikimedia.org/T236800 (10Krinkle) I've reviewed the [commits since 5.1.17](https://github.com/krakjoe/apcu/commits/master) and nothing else stands out...
[14:24:04] <wikibugs>	 10serviceops, 10Core Platform Team, 10Graphoid, 10Operations: Undeploy graphoid - https://phabricator.wikimedia.org/T242855 (10akosiaris)
[14:24:12] <wikibugs>	 10serviceops, 10Core Platform Team, 10Graphoid, 10Operations: Undeploy graphoid - https://phabricator.wikimedia.org/T242855 (10akosiaris) p:05Triage→03Normal
[14:27:04] <wikibugs>	 10serviceops: Decide on librdkafka deployment model for k8s services - https://phabricator.wikimedia.org/T242810 (10Ottomata) I'm for it!  I'd like to be able to use the librdkafka version that makes sense for the service, especially now that we have containerization.  Depending on the .deb package can slow thin...
[14:27:14] <ottomata>	 akosiaris:  hellloooo
[14:28:56] <akosiaris>	 ottomata: hi
[14:29:28] <ottomata>	 question of the morning: which canary impl? :p
[14:29:49] <ottomata>	 (not urgent, but i was thikning of using it in the wip eventstreams chart too)
[14:30:26] <ottomata>	 i don't mind addressed_by, but I'm not really sure it is needed
[14:30:41] <ottomata>	 i do think we need a new service label though, set by values.servce.name
[14:31:09] <ottomata>	 otherwise the stuff in eventgate is going to get weird, since i'm currently using wmf.releasename, which is chart-release
[14:31:17] <ottomata>	 and we are now varying release within the same service
[14:31:31] <akosiaris>	 we are?
[14:31:35] <ottomata>	 yeah
[14:31:36] <ottomata>	 canary
[14:31:41] <akosiaris>	 nope, the new patch doesn't
[14:31:50] <ottomata>	 there's no helmfile change?
[14:31:56] <ottomata>	 oh
[14:32:02] <ottomata>	 yes, you keep the release label the same
[14:32:03] <ottomata>	 but
[14:32:14] <ottomata>	 meaning it always matches .Release.Name
[14:32:16] <ottomata>	 but .Release.Name changes
[14:32:52] <ottomata>	 and 
[14:32:54] <ottomata>	 wmf.releasename
[14:32:56] <ottomata>	 is chart-release
[14:33:06] <ottomata>	 .Chart.Name-.Release.Name
[14:33:16] <akosiaris>	 ottomata: I am knee deep right now into betterworks, OKRs and a meeting in a few
[14:33:20] <ottomata>	 OK
[14:33:22] <ottomata>	 hah
[14:33:25] <ottomata>	 sorry np!
[14:33:42] <akosiaris>	 wanna write down in an etherpad/task what the issue is and I 'll try to comment tomorrow?
[14:34:02] <ottomata>	 hm ya we don't have a task for this
[14:34:03] <ottomata>	 will make one
[14:34:03] <ottomata>	 ty
[14:34:04] <akosiaris>	 cause my attention is split like over 4 things simultaneously and I am starting to fail at all of them
[14:34:09] <ottomata>	 <3
[14:34:10] <akosiaris>	 sorry btw
[14:34:13] <ottomata>	 bp!
[14:34:14] <ottomata>	 np!
[14:48:28] <wikibugs>	 10serviceops, 10Recommendation-API, 10Release-Engineering-Team, 10Services, 10Patch-For-Review: Migrate  recommendation-api to kubernetes - https://phabricator.wikimedia.org/T241230 (10akosiaris) Images for buster and nodejs10 have been been created and are present in the registry
[14:54:54] <wikibugs>	 10serviceops, 10Recommendation-API, 10Release-Engineering-Team, 10Services, 10Patch-For-Review: Migrate  recommendation-api to kubernetes - https://phabricator.wikimedia.org/T241230 (10akosiaris) >>! In T241230#5795628, @bmansurov wrote: > @akosiaris thanks for the patch. What are the next steps once you...
[15:15:40] <wikibugs>	 10serviceops, 10Analytics, 10Product-Analytics (Kanban): Clarify multi-service instance concepts in helm charts and enable canary releases - https://phabricator.wikimedia.org/T242861 (10Ottomata)
[15:21:17] <wikibugs>	 10serviceops, 10Operations, 10ops-eqiad: (Need By: Jan 10) rack/setup/install mc-gp100[123].eqiad.wmnet - https://phabricator.wikimedia.org/T241795 (10Cmjohnson)
[18:16:30] <wikibugs>	 10serviceops, 10Operations, 10Phabricator, 10Traffic, 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)): Phabricator downtime due to aphlict and websockets (aphlict current disabled) - https://phabricator.wikimedia.org/T238593 (10mmodell) p:05Normal→03High
[18:22:56] <wikibugs>	 10serviceops, 10Operations, 10Release Pipeline, 10Release-Engineering-Team, 10User-brennen: Remove obsoleted docker images - https://phabricator.wikimedia.org/T242604 (10brennen)
[18:23:36] <wikibugs>	 10serviceops, 10Core Platform Team, 10Performance-Team, 10Release-Engineering-Team-TODO, and 5 others: Define variant Wikimedia production config in compiled, static files - https://phabricator.wikimedia.org/T223602 (10thcipriani)
[18:24:38] <wikibugs>	 10serviceops, 10Operations, 10Scap: Make canary wait time configurable - https://phabricator.wikimedia.org/T217924 (10jijiki)
[18:25:52] <wikibugs>	 10serviceops, 10Operations, 10Scap: Make canary wait time configurable - https://phabricator.wikimedia.org/T217924 (10jijiki) @thcipriani as per our discussion, we can consider merging and testing first for syncing files and then on the train. How does that sound?
[19:14:55] <wikibugs>	 10serviceops, 10Operations, 10ops-eqiad, 10Patch-For-Review: (Need By: Jan 10) rack/setup/install mc-gp100[123].eqiad.wmnet - https://phabricator.wikimedia.org/T241795 (10Cmjohnson)
[23:24:42] <wikibugs>	 10serviceops, 10ChangeProp, 10Release Pipeline, 10Release-Engineering-Team-TODO, and 3 others: Migrate changeprop to kubernetes - https://phabricator.wikimedia.org/T213193 (10Pchelolo) After a bunch of fighting with corrupted change-prop repo on gerrit and with help from RelEng, we now have a working image...