Install Status, Hardware Status or Operational Status?

[mbourla]

Am revisiting this old question, to understand which status field to use on CIs - install_status, hardware_status or operational_status.   Would be keen to know what other people are doing around this.

The 3 OOTB status fields are:

• hardware_status (and hardware_substatus) : defined on cmdb_ci_hardware, so only available for hardware.
• install_status : defined on the cmdb table (in recent versions, previously cmdb_ci), so can be used on all CI types (including hardware)
• operational_status : defined on cmdb_ci, so can be used on all CI types (including hardware).

https://community.servicenow.com/thread/221800 says that hardware_status is legacy, so to use install_status.

https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/product/configuration-managemen... describes how operational_status is sync'd with hardware_status (on hardware CIs) or with install_status (on non-hardware CIs).   I didn't know that before. But from experimenting, it only syncs operational_status with one or other of install_status and hardware_status, not both.   Which isn't terribly helpful (but can be customised of course).

https://community.servicenow.com/message/840145#840145 advises to ignore operational_status and use install_status.

So the conclusion so far is to go with just install_status for all CI types.

But... from https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/product/configuration-managemen... it's operational_status which the new CI Lifecycle Management works with.

Which implies that ServiceNow intend people to use operational_status as the primary status field.

So the question is... to stick with install_status, which keeps things simple?   Or use operational_status, to allow future use of CI Lifecycle Management?   Or use both install_status AND operational_status, where I'd see operational_status being like a sub-status for install_status (and the choices tweaked to remove the overlap & duplication).

Thoughts welcome!!

Thanks

Michael

[Paul Coste2]

I agree it is confusing.   From a look at the code, the Install Status is what is synchronized at a minimum, using the states specified in alm_asset_ci_state_mapping table, but if your CIs/Assets are Hardware, as you mention, then it will also synchronize the Hardware Status and Substatus field using alm_hardware_state_mapping.   Take a look at the AssetAndCISynchronizer script.   This logic was previously hard-coded, but it seems they have made this more generic in the last couple of releases.   The fact that they are actually building more generic mapping seems to suggest to me that none of these fields should really be considered "legacy".   Also very confusing that this is based on the CI class, as the actual class inheritance of Hardware is inconsistently used.   Operational status seems to be more focused on CI/Service Lifecycle than the status of the CI itself.   It have read that it was incorporated into the CI Lifecycle Management.  

Overall I think there is a lot of ambiguity and overlap of these fields, and yet there is still out of box business logic tied to all of them, so it seems to me that customers either need to understand all of this business logic to use it out of box, or customize it to suit their own needs and face potential compatibility questions.   Either way there are challenges.

[mbourla]

Just an update from me on this... with the aim of getting a definitive answer I raised a ticket on HI.   They said to use hardware_status and hardware_substatus for CIs on cmdb_ci_hardware (or below), and otherwise use install_status.   And that additionally there is operational_status, which is "set by features such as Discovery".

However, one of my colleagues has discussed this with the person at ServiceNow who wrote or looks after the asset management application, and was told that the hardware status and substatus fields were legacy and shouldn't be used.   I expect those fields date back to when assets were stored in the CMDB (as I understand it), many releases ago.

I can see that the code that syncs CIs and assets does work off both hardware_status (if it's in use) and install_status (otherwise).   Which is presumably to cater for people still using hardware_status.

Also, I can see code that runs off Operational Status for Business Service CIs, which means it's not just to do with discovery.  

All extremely confusing!  

Anyway, I'm going to primarily go with just install_status, as both of you advised.

Thanks again for your input.

[cyked]

Lots of good replies.

I'll add that Operational Status can be used for monitoring.   Do we expect this record to be operational,and thereby should monitored events be paid mind or not.

There are a few rules around Parent/Child table inheritance when it comes to install_status on CI.   I'lll use servers as an example.

If you have customized nothing, if you add an install_status value at cmdb_ci_server, all extended tables inherit (windows, linux, AIX, etc).

If you add an install_status value at AIX server the ENTIRE table of sys_choice for AIX Server is considered custom and all values at AIX Server are considered custom, which means you need to, at AIX server, list all valid values for install_status you want to be selectable.

[Chris Bui]

This was a very helpful thread!  Thank you to all contributors!  

To summarize to my understanding after reading this... please correct me if I'm wrong

• install_status is the primary status field that is native to all cmdb and asset classes
• operational_status is native to all cmdb classes and its use is complementary to install_status
• hardware_status is native to the hardware subset of the cmdb and appears to be legacy

[Paul Coste2]

I think there is still some room for opinion on this.  Since ServiceNow is not only continuing to support hardware_status but also have refactored the way it synchronizes between assets and CIs, it is not clear to me that this is truly "legacy".  Which status fields you use seems to depend on how you choose to implement configuration management and asset management processes.

Also note:

• with the Service Portfolio plugin, there are additional status fields added to the cmdb_ci_service CI class to represent the state of the business service in the service pipeline and in the catalog; note also that these fields to not synchronize with the other status fields, so you need to add business rules to accomplish this
• the CI Lifecycle Management component seems to want to use "operational status" as its field of choice, though from what I can see this component is not very fleshed out.  Is anyone actually using it?  I did note in the documentation that certain values of operational status are hard-coded.
• There is also substatus, which is not listed here.
• Since all hardware should link to an asset record, you'll also need to account for the asset status and how it is mapped to the CI status in both directions.  While they have improved the ability to keep status (and other fields) in sync between asset and CI status, you will likely need to modify the rules of your specific process, data model, naming conventions, standards, etc.