Page MenuHomePhabricator

decommission wdqs200[7-8]
Open, MediumPublicRequest

Description

This task will track the decommission-hardware of servers wdqs200[7-8] .

Refresh ticket: T376669
These hosts will be replaced by wdqs202[67] , see T378031

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.

wdqs2007

Steps for service owner:

  • - all system services confirmed offline from production use
  • - set all icinga checks to maint mode/disabled while reclaim/decommmission takes place. (likely done by script)
  • - remove system from all lvs/pybal active configuration
  • - any service group puppet/hiera/dsh config removed
  • - 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.
  • - 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.
  • - remove all remaining puppet references and all host entries in the puppet repo
  • - 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

wdqs2008

Steps for service owner:

  • - all system services confirmed offline from production use
  • - set all icinga checks to maint mode/disabled while reclaim/decommmission takes place. (likely done by script)
  • - remove system from all lvs/pybal active configuration
  • - any service group puppet/hiera/dsh config removed
  • - 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.
  • - 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.
  • - remove all remaining puppet references and all host entries in the puppet repo
  • - 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

Event Timeline

bking mentioned this in Unknown Object (Task).
brouberol subscribed.

Following up on our Slack conversation, we don't want to decom wdqs2008 quite yet, as it is a wdqs-internal host and we don't want to lose any capacity on that tier. Why? Because the internal hosts currently host deepcat (aka wdqs-categories) for all wikis. As such, we are blocked from decommissioning wdqs2008 until T385896 is finished. (We could technically just decom wdqs2007, but there's no urgency so I'd prefer to wait).

I suspect that we might want to keep those servers available for the transition away from Blazegraph (see T409769). We do have a few test servers in eqiad already, but non in codfw. For the testing phase, that's ok, but for the deployment phase, we'll want some over capacity in codfw as well.

Given the regular overload of WDQS, should we really decom those servers? My intuition is that the spikes in load will overload the cluster whatever the size and removing those servers will not make the situation worse.

@Gehel , I'm interpreting your comment as

removing those servers will not make the situation worse.

Let me know if I'm off-base on this. If that is your intent then I agree: we should not decommission these hosts any time soon. Should we move the task back out of the sprint and tackle it once we're done migrating off of Blazegraph?

removing those servers will not make the situation worse

This wasn't a typo, I'm somewhat expecting that whatever the resources we throw at the problem, peak traffic will be problematic in the current context.

But it makes a lot of sense to keep the capacity for as long as we can. @bking : I'll let you coordinate with DC-Ops.