people1001, the backend for https://people.wikimedia.org is currently running on stretch and should be upgraded to buster
time frame: by the end of Q2 2020
people1001, the backend for https://people.wikimedia.org is currently running on stretch and should be upgraded to buster
time frame: by the end of Q2 2020
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Stalled | None | T302086 Set scap minimum python version to 3.7 | |||
Resolved | None | T247045 Migrate all of production metal and VMs to Buster or later | |||
Resolved | Dzahn | T247649 upgrade people.wikimedia.org backend to buster | |||
Resolved | Dzahn | T249907 eqiad/codfw: 1 each VM request for people.wikimedia.org | |||
Resolved | Dzahn | T253296 decom people1001 |
Change 587982 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/dns@master] add people1002.eqiad.wmnet
Change 588647 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/dns@master] add people2001.codfw.wmnet
Change 595927 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] site: add people1002
Change 595951 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] DHCP: add people1002.eqiad.wmnet
Change 595951 merged by Dzahn:
[operations/puppet@production] DHCP: add people1002.eqiad.wmnet
Change 595956 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] site: add peopleweb role to people1002
Change 595957 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/dns@master] add IPv6 records for people1002
Change 595959 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/dns@master] switch peopleweb service/discovery names to people1002
Change 595957 merged by Dzahn:
[operations/dns@master] add IPv6 records for people1002
Change 595956 merged by Dzahn:
[operations/puppet@production] site: add peopleweb role to people1002
Change 596151 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] peopleweb: allow rsyncing /home to a new server
Change 596151 merged by Dzahn:
[operations/puppet@production] peopleweb: allow rsyncing /home to a new server
Change 595959 merged by Dzahn:
[operations/dns@master] switch peopleweb service/discovery names to people1002
Change 597751 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] site: remove peopleweb role from people1001
Mentioned in SAL (#wikimedia-operations) [2020-05-21T10:07:38Z] <mutante> replaced backend of people.wikimedia.org - people1001 will be inaccessible, replaced with people1002 on buster. all home dirs have been synced over, there should be no difference except you have to use people1002 now for uploads (T247649)
Change 597751 merged by Dzahn:
[operations/puppet@production] site: remove peopleweb role from people1001
Change 597757 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] ATS: fix never_cache rule to apply to peopleweb discovery name
Change 597757 merged by Dzahn:
[operations/puppet@production] ATS: fix never_cache rule to apply to peopleweb discovery name
Change 597758 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] peopleweb: set rsync_src and rsync_dst host to the same server
Change 597758 merged by Dzahn:
[operations/puppet@production] peopleweb: set rsync_src and rsync_dst host to the same server
I think there are still some bits in the DNS repo that point to the old instance:
templates/wmnet:people 5M IN CNAME people1001.eqiad.wmnet. templates/wmnet:peopleweb 300 IN CNAME people1001.eqiad.wmnet.
@Dzahn my bad, I had a silent error during the update of my local git copy that lead to this mis-finding.
FWIW it's also possible to ssh directly into the "right" instance using ssh people.eqiad.wmnet if the script provided in [1] is used that ensures that the right fingerprint is checked against.
[1] https://wikitech.wikimedia.org/wiki/Production_access#Known_host_files