Tracking ticket for the setup of servers allocated on RT 9110.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Dzahn | T94474 reclaim / decom haedus and capella | |||
| Declined | • Manybubbles | T84902 deploy haedus and capella with os for orientdb testing | |||
| Resolved | Papaul | T84901 label/setup/update servers haedus & capella |
Event Timeline
old name: solr2
new name: haedus
asset tag: WMF5834
mgmt ip: 10.193.2.1
port #: ge-5/0/20
old name: solr3
new name: capella
asset tag: WMF5835
mgmt ip: 10.193.2.2
port #: ge-5/0/21
pulling info for mac addresses and setting up the network ports now
haedus online post OS install, puppet/salt keys NOT signed.
As OS is online, but I don't see a related ticket for the testing of this (I am likely missing it), I'm just going to reassign this particular task from myself to Giuseppe for work.
Haedus was NOT online post-install, it was in a busybox and it's presently reimaging because it could not find the root filesystem.
Capella only sees one disk, at pci-0000:01:00.0-scsi-0:2:0:0, this needs investigation. Moving the ticket to the codfw queue
It seems I accidentally didnt notice and break the raid config setup on capella, as it uses an H310. A quick look confirms haedus does as well.
So now capella is reinstalled with the h310 in bypass mode, presenting the disks normally.
So this should be good to go, going to remove the codfw onsite flag, as there isn't any onsite work to be done.
If these aren't good for this testing, joe mentioned the old lsearch systems would also work. So this is allocated for the testing, but can be swapped if it turns out to not be ideal.
Should have a decom/reclaim ticket to follow-up with https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Reclaim_or_Decommission