I can't find references to them under operations/puppet, operations/mediawiki-config, or cloud/instance-puppet. We seem to use 0[45] with 08 as a buster testing machine.
They run Jessie and I've been looking at the parent task wondering why we have so many memc boxes.
If they're not needed can we shut them down / terminate them?
Tyler: It looks like you made these in late November 2018. Any ideas?
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T197804 Puppet: forbid new Python2 code | |||
Open | None | T218426 Upgrade various Cloud VPS Python 2 scripts to Python 3 | |||
Resolved | BUG REPORT | Bstorm | T218423 Add python 3 packages to openstack::clientpackages::common | ||
Resolved | MoritzMuehlenhoff | T232677 Remove support for Debian Jessie in Cloud Services | |||
Duplicate | None | T236575 "deployment-prep" Cloud VPS project jessie deprecation | |||
Resolved | None | T218729 Migrate deployment-prep away from Debian Jessie to Debian Stretch/Buster | |||
Resolved | thcipriani | T250585 Determine purpose of deployment-memc0[67] |
Event Timeline
From openstack-browser:
deployment-memc04.deployment-prep.eqiad.wmflabs debian-8.3-jessie (2016-06) 172.16.5.76 deployment-memc05.deployment-prep.eqiad.wmflabs debian-8.3-jessie (2016-06) 172.16.5.17 deployment-memc06.deployment-prep.eqiad.wmflabs debian-8.9-jessie (2017-09) 172.16.5.12 deployment-memc07.deployment-prep.eqiad.wmflabs debian-8.9-jessie (2017-09) 172.16.5.2 deployment-memc08.deployment-prep.eqiad.wmflabs debian-10.0-buster (2019-12) 172.16.0.28
From operations/puppet.git:
redis::shards: sessions: eqiad: shard01: host: 172.16.5.76 port: 6379 shard02: host: 172.16.5.17 port: 6379 shard03: host: 172.16.5.12 port: 6379 shard04: host: 172.16.5.2 port: 6379
From Horizon hiera:
redis::shards: sessions: eqiad: shard01: host: 172.16.5.76 port: 6379 shard02: host: 172.16.5.17 port: 6379 shard03: host: 172.16.5.12 port: 6379 shard04: host: 172.16.5.2 port: 6379
This suggests that four servers (memc04 through memc07) are currently in-use by appserver/nutcracker for Main Stash (incl. legacy sessions).
It seems that memc08 (Buster) is newer and not in use.
Tyler: It looks like you made these in late November 2018. Any ideas?
It looks like I added memc05/06 so that @aaron could test mcrouter replication (per T175418: Create new instances memc05 and memc06 running memcached). Not sure why 07 was added offhand.
Mentioned in SAL (#wikimedia-releng) [2021-03-05T20:23:37Z] <James_F> Disabling deployment-memc07 on the grounds that it's an unreferenced Jessie box we don't want any more T250585
Mentioned in SAL (#wikimedia-releng) [2021-03-05T20:25:00Z] <James_F> Disabling deployment-memc06 on the grounds that it's an unreferenced Jessie box we don't want any more T250585
Mentioned in SAL (#wikimedia-releng) [2021-03-07T15:28:06Z] <Majavah> remove and shard04 (deployment-memc07) from redis::shards, switch shard03 from deployment-memc06 to deployment-memc09, [06-07] are both already shut down and 09 is a new in setup Buster machine to replace it, T276707 T250585