What's the best practice for changing life cycle control for an OOTB life cycle mapping?

[Caleb Cordes]

The life cycle mapping for Configuration Item: "Operational Status - Non-Operational"  to "Configuration Item - Design - Build" not make sense for all use cases. For instance users may put a CI in Non-Operational status when the CI is turned down and pending retirement. I assume it's not best practice to update the lifecycle Control, but can someone tell me what the impact would be? What's the best practice in this case?

[cassieb_ · Accepted solution]

It's a great question you are asking. I would consider what might come as part of CSDM 5.0... I understand that they are supposed to be announcing that this week at Knowledge 24.

The other consideration is to evaluate the Life Cycle Mappings table after upgrades/patches in your lower environments to see if a Life Cycle Mapping you created comes into conflict with any newly created or updated OOB Life Cycle Mappings.

[Lyle Taylor]

We have found that the way Non-Operational gets set in different scenarios with OOB discovery, it appears that it does not have a consistent usage or meaning across all the scenarios. We also don't feel that there are appropriate Life Cycle Stage/Status values to represent it in many of the cases where it is being set. For example, in a cluster for an F5 BIG-IP load balancer, the standby node gets set to Non-Operational, but it doesn't make sense that this node would get set to Design/Build. Similarly, server discovery will mark some disks and partitions as Non-Operational, and again, I don't think that they're in a Design/Build state. In the cases where we cared what the new Life Cycle Stage/Status field values are, we have added or updated the mappings so that it maps to our desired values for the new fields. So, for example, with the F5 BIG-IP scenario, we have decided that both Operational and Non-Operational will map to Operational/In Use, since the standby node really is still operational - it's just not the active node.