Talk:Server Lifecycle

Rendered with Parsoid
From Wikitech
Latest comment: 4 years ago by Jcrespo in topic Stages

Hey, how about using the discussion page :-P

Since we are committing to doing everything from puppet disable to power off in one shot (not in days but in an hour let's say), no point in waiting for the daily storedconfig cron cleanup job based on decomm.pp. So I removed that, and added some comments later about how we don't rely on that mechanism. We want to get away from that anyways since this file is eventually to be tossed.

Fixed order: we remove from puppet manifests etc before we disable puppet on the host. And we can do any of those removal steps and stop in the middle before we commit to the process leading to power off.

In theory one could write a script that did puppet disable/storedconfigs clean/remove cert/remove salt key and do all that with one command. This would make it impossible to back out if there were issues with icinga refresh but if we ensured that there wa always someone who could look at and fix those issues when this script is run, that would be ok. Note that puppet node clean (available from puppet 2.7.10 on) removes the cert and cleans up exported resources, so we should start using it instead of puppetstoredconfigclean.

Comments/complaints/corrections please... -- ariel (talk) 09:48, 4 November 2013 (UTC)Reply

Introducing Netbox

Netbox will replace Racktables, the following one is the proposal to adapt our current Server Lifecycle to the introduction of Netbox

Netbox available statuses

Those are the currently available statuses in Netbox:


Lifecycle defined statuses

Lifecycle statusNetbox status
requestednone, not yet in Netbox
recyclednone, not anymore in Netbox

Lifecycle transitions

Only the high level overview is described here, it will be integrated into the page itself.

Diagram of the Lifecycle transitions
Diagram of the Lifecycle transitions

requested -> spare

  • DC Ops receives the shipment to the datacenter (not yet racked)
  • DC Ops adds device to Netbox, with status PLANNED

spare -> staged

  • DC Ops racks the device, if not already racked
  • DC Ops performs the initial setup (operating system installed, puppet etc.)
  • DC Ops assigns a rack position in Netbox, and changes status from PLANNED to STAGED

staged -> active

  • service owner performs acceptance tests and (re)provisions their service
  • service owner changes Netbox's status from STAGED to ACTIVE

active -> decommissioned

  • service owner perform actions to remove it from production
  • service owner changes Netbox's status from ACTIVE to INVENTORY

active -> staged

This transition should be used when reimaging the first host of a cluster into a newer OS that will likely need to be tested extensively before putting it back in production. It can be used also in other occasions when a rollback of the STAGED -> ACTIVE transition is needed.

  • service owner perform actions to remove it from production
  • service owner changes Netbox's status from ACTIVE to STAGED

active -> failed

  • service owner perform actions to depool it from production
  • service owner changes Netbox's status from ACTIVE to FAILED

failed -> staged

  • DC Ops fixes the hardware failure
  • DC Ops changes Netbox's status from FAILED to STAGED

decommissioned -> spare

  • DC Ops wipe power down the host, renaming its hostname to its WMF Asset Tag. (Network switch port is also disabled.)
  • DC Ops changes Netbox's status from INVENTORY to PLANNED

decommissioned -> staged

This transition is for renames and immediate re-allocations into a different role

  • DC Ops wipe and reimage into role::spare the host with the new name
  • DC Ops changes Netbox's status from INVENTORY to STAGED

failed | spare | decommissioned -> unracked

When decommissioning a failed host beyond repair, an old host that was sitting as a spare, normal decommissioning

  • DC Ops unracks the device, and removes the row/rack association in Netbox
  • DC Ops changes Netbox's status to OFFLINE
  • DC Ops places device in the data center's storage unit
  • DC Ops adds device to the "Operations tracking" document, in the "unracked decomissioned" sheet [to be automated]
  • DC Ops (eventually) communicates this (e.g. on a quarterly basis) to Finance, to be written off the books

unracked -> recycled

  • DC Ops ships the device off to a recycler company
  • DC Ops adds the device to the "Operations tracking" document, in the "sold-decom servers" sheet and removes it from the "unracked decomissioned" sheet [to be automated]
  • DC Ops communicates the device to Finance as a "sold-off server"
  • DC Ops deletes the device from Netbox entirely (previously: moves to a decom rack in Racktables)


  • The spare term is overloaded, as it's used to describe two different points in the lifecycle of a host.
    1. Host offline & wiped with just the management interface connected and online: spare lifecycle status
    2. Host online, has puppet role spare::system: staged lifecycle status and normal hostname. These hosts are either about to be pushed into service, or are in the process of being removed from service.
  • Renames: active -> decommissioned -> staged with the new name, skipping the spare status
  • Decommission of a production host back into the spare pool: it's a rename to its WMF asset tag.
  • Relationship between racked/unracked, power on/off and their Netbox status:
Netbox statusRackedPower
PLANNEDyes or nooff
FAILEDyeson or off

Open questions

  • Power on/off status: if needed we could add a custom field to Netbox to track the power status, not sure it's worth though and can be added at a later stage too.
  • Should the wipe+reimage process be done on active -> decommissioned by the service owner instead of doing it in the next step?
  • When we want to start to track IPs and VLANs association in Netbox

Changes to be made to the page sections

This is a minimal list of required changes to be made to this wiki page to include the Netbox steps. We can then restructure the page to follow the above lifecycle statuses.

  • Server states
    • Requested: kept as is
    • Existing System Allocation: to be split into the DECOMMISSION -> STAGED and STAGED -> ACTIVE, as it is right now is basically only the latter transition.
    • Ordered: kept as is
    • Post order: kept as is
    • Receiving Systems On-Site: change insert into Racktables with insert into Netbox with status PLANNED. If the hostname is not available at this time, insert it without an hostname, the asset tag has it's own field.
    • Racked: change update Racktables to update Netbox with the hostname (if it was inserted without) and rack location
    • Installation: if the hostname is chosen at this time, update Netbox with it.
    • In Service: kept as is
    • Reinstallation: add a note for the ACTIVE -> STAGED transition to put the host in Netbox in STAGED if needed (not for normal depool -> reimage -> pool transitions).
    • Reclaim to Spares OR Decommission
      • Steps for ANY Opsen: add change Netbox status from ACTIVE reimage into spare::system keeping the systems current hostname (unless already re-assigned to a different name/role).
      • Steps for DC-OPS (with network switch access): add change Netbox status from INVENTORY to OFFLINE, wipe disks, rename host to WMF asset tag in netbox and on disabled network switch port.
  • wmf-auto-reimage: kept as is (an CLI option could be added later on to the script to automatically change Netbox status on reimages that need to be put in STAGED).
  • Server reimage + rename: add active -> decommissioned -> staged status changes
  • Position Assignments: kept as is
  • See also: kept as is


The documentation here is not showing realitiy- the stages on netbox are not the same as the ones mentioned here. It would be nice whoever maintains netbox or this docs to review it and sync it.

My other request is to explain a bit more the stages on the initial paragraph. Active is more or less clear, but there are several stages of "inactivity" that aren't 100% clear to me. ---- Jcrespo 14:47, 5 June 2019 (UTC)Reply