Change Details

This task will track the #decommission of server <enter FQDN of server here>. With the launch of updates to the decom cookbook, the majority of these steps can be handled by the service owners directly. The DC Ops team only gets involved once the system has been fully removed from service and powered down by the decommission cookbook. <ENTER SINGLE HOSTNAME PER CHECKLIST HERE> **Steps for service owner:** [x] - all system services confirmed offline from production use [x] - set all icinga checks to maint mode/disabled while reclaim/decommmission takes place. (likely done by script) [x] - remove system from all lvs/pybal active configuration [x] - any service group puppet/hiera/dsh config removed [x] - remove site.pp, replace with role(spare::system) recommended to ensure services offline but not 100% required as long as the decom script is IMMEDIATELY run below. [x] - login to cumin host and run the decom cookbook: cookbook sre.hosts.decommission <host fqdn> -t <phab task>. This does: bootloader wipe, host power down, netbox update to decommissioning status, puppet node clean, puppet node deactivate, debmonitor removal, and run homer. [x] - remove all remaining puppet references and all host entries in the puppet repo [x] - reassign task from service owner to no owner and ensure the site project (ops-sitename depending on site of server) is assigned. **End service owner steps / Begin DC-Ops team steps:** [] - system disks removed (by onsite) [] - determine system age, under 5 years are reclaimed to spare, over 5 years are decommissioned. [] - IF DECOM: system unracked and decommissioned (by onsite), update netbox with result and set state to offline [] - IF DECOM: mgmt dns entries removed. [] - IF RECLAIM: set netbox state to 'inventory' and hostname to asset tag Original task description: Is anybody using this host? The only reference I found is in T229559, and it looks like it's the replacement for clouddb2001-dev, which in turn was used as a database for the codfw OpenStack deployment (see e.g. T220096). The host name can cause some confusion because it uses the same naming scheme of the wikireplica hosts `clouddb10*`, but from what I can understand it has nothing to do with wikireplicas.

This task will track the #decommission of server <enter FQDN of server here>. With the launch of updates to the decom cookbook, the majority of these steps can be handled by the service owners directly. The DC Ops team only gets involved once the system has been fully removed from service and powered down by the decommission cookbook. <ENTER SINGLE HOSTNAME PER CHECKLIST HERE> **Steps for service owner:** [x] - all system services confirmed offline from production use [x] - set all icinga checks to maint mode/disabled while reclaim/decommmission takes place. (likely done by script) [x] - remove system from all lvs/pybal active configuration [x] - any service group puppet/hiera/dsh config removed [x] - remove site.pp, replace with role(spare::system) recommended to ensure services offline but not 100% required as long as the decom script is IMMEDIATELY run below. [x] - login to cumin host and run the decom cookbook: cookbook sre.hosts.decommission <host fqdn> -t <phab task>. This does: bootloader wipe, host power down, netbox update to decommissioning status, puppet node clean, puppet node deactivate, debmonitor removal, and run homer. [x] - remove all remaining puppet references and all host entries in the puppet repo [x] - reassign task from service owner to no owner and ensure the site project (ops-sitename depending on site of server) is assigned. **End service owner steps / Begin DC-Ops team steps:** [x] - system disks removed (by onsite) [x] - determine system age, under 5 years are reclaimed to spare, over 5 years are decommissioned. [x] - IF DECOM: system unracked and decommissioned (by onsite), update netbox with result and set state to offline [x] - IF DECOM: mgmt dns entries removed. [x] - IF RECLAIM: set netbox state to 'inventory' and hostname to asset tag Original task description: Is anybody using this host? The only reference I found is in T229559, and it looks like it's the replacement for clouddb2001-dev, which in turn was used as a database for the codfw OpenStack deployment (see e.g. T220096). The host name can cause some confusion because it uses the same naming scheme of the wikireplica hosts `clouddb10*`, but from what I can understand it has nothing to do with wikireplicas.