967082 - What does decommissioning in Inventory mean?

Status: RESOLVED WORKSFORME

(Infrastructure & Operations Graveyard :: WebOps: Inventory, task)

Description

[Jacques Uber [:uberj]]

I want to wrap the action of 'decommissioning' a system into a one-stop-shop API. To do this I need to come up with an exact (or almost exact) process to follow when decommissioning something.

I know I'm going to:
    1. Set the system status to 'decommissioned'
    2. Decommission SREG objects and offer to delete related DNS records (build.mozilla.org CNAMEs)
    3. Disables any HWAdapter objects attached to decommissioned SREG objects.

My question is about:
    4. Should we blank the operating_system field?
    5. Should we blank the allocation field? (who owns the system)
    6. Should we blank the switch port values (switch_ports, oob_switch_port)?
    7. Should we blank the oob_ip?

Is there anything else that should be changed upon decommissioning? If different groups truly need different decommission procedures we can add option flags to the invtool script that will be performing this action.

Comment 1

[Jacques Uber [:uberj]]

I'm needinfo-ing people who I think have a stake in how a system is decommissioned

Comment 2

[Amy Rich [:arr] [:arich]]

My general opinion on decommissioning is that the only information that's left in inventory should be hardware or process-specific.  This includes:

1) setting the system status to decommissioned
2) deleting any DNS records that are assigned to the host (including CNAME, MX, A, PTR, SRV, etc)
3) deleting any DHCP records that are assigned to the host (but keeping a record of the MACs since that's hardware specific).
4) deleting the operating system
5) deleting allocation (no one owns it anymore and it should not show up in any allocation-based searches).
6) deleting the switch ports and oob switch ports since the machine is no longer hooked up to a switch
7) deleting the oob_ip since the DNS record will no longer exist and this information will be inaccurate
8) deleting the patch panel port (again, it's no longer hooked up to anything)
9) deleting rack and rack location OR setting it to a specified storage location (I think the latter is what dcops does now).
10) delete information from the k/v store if it exists (pdus, any information related to the panda chassis and imaging servers, etc)

The last is more difficult since the k/v store is free form, so I'm willing to ignore that one if it's too difficult to manage.

What should be left:
1) inventory host name
2) created on date
3) serial number
4) system type
5) asset tag
6) purchase date
7) purchase price
8) warranty start and end
9) server model
10) MACs associated with each interface (where we had that info in the first place)
11) any notes that were part of the inventory record

Comment 3

[Hal Wine [:hwine] use NI!]

Before we detail what field updates "decommission" should affect, I'd like to be sure we all agree on when to use the term "decommission".  

To me, that means understanding the life cycle of a piece of hardware from the releng perspective. There may be more fine-grained states needed by various IT groups, but I think releng cares about the following states (I'll confirm):

 - host is fully ready for use by releng (all physical, network, and one-time setup complete)

 - host is out of service for some major reason (e.g unracked for outside maintenance)

 - host is not in use (powered off), but being kept "just in case" (e.g. some r3 boxes currently)

 - host is no longer of any use to releng (either transferred to another group, or taken to the ewaste)

Note: I'm not saying inventory system needs to support these 4 states, just that we know how to map them onto "views" of the inventory system. And, that we don't accidentally use a term that has specific meaning to IT the "wrong way". (I believe the latter has happened and why we're in this discussion.)

Comment 4

[Amy Rich [:arr] [:arich]]

:hwine: FYI we were talking about this on irc because we wanted a way to fully decommission a host, not because of any specific way that releng uses state names.

Comment 5

[Hal Wine [:hwine] use NI!]

(In reply to Amy Rich [:arich] [:arr] from comment #4)
> :hwine: FYI we were talking about this on irc because we wanted a way to
> fully decommission a host, not because of any specific way that releng uses
> state names.

And in that irc discussion it was stated (by uberj? my scrollback expired) that releng had a different idea of "decom" than dcops -- that's what I want to clear up. I'm fine if we say that "in the IT sense, releng never decom's anything", and IT always translates for us so the correct thing happens. :)

Comment 6

[Amy Rich [:arr] [:arich]]

By "different idea" he meant that our decomm list has things like zeroing out the OS, oob ip, switch ports, etc.  Infra does not do these things.  The conversation was not about spare vs decomm or error/service (all of which exist as states in inventory).

Comment 7

[Hal Wine [:hwine] use NI!]

Since relops says they support the releng business needs in comment 6 without confusion, I have no opinion on anything else. Y'all own the fields.

I have confirmed we'll essentially be using the same 4 states with AWS, and presumably other virtual/cloud services.