Inconsistent 'End of Life / Retired' config (Life Cycle Control, Life Cycle Mapping & Data Manager)

PG2
Tera Expert

‎10-12-2023 09:45 PM

In the Vancouver release, End of Life / Retired is no longer a valid combination for cmdb_ci_hardware CIs (the introduction of an active column in the life_cycle_control table is set to false ootb) - see attached.

 

Inconsistency 1 - CMDB Data Manager will set the CI Lifecycle Stage / Status to End of Life / Retired after a policy is executed.

 

Does this mean we should not use data manager for life cycling hardware CIs? If it's ok to setup retire policies for hardware, then the tooling will set the CI to End of Life / Retired which is inconsistent with the control table configuration preventing the combination.

 

Inconsistency 2 - The ootb CSDM life cycle mapping has an entry which maps both the operational status (retired) and install status (retired) of a cmdb_ci_server CI to End of Life / Retired. Again, this is inconsistent considering cmdb_ci_server is a child of hardware.

 

Has anyone come across these inconsistencies and can shed any light on what the intent is?

 

Screenshot 1 - Life Cycle Control

 

life cycle control ootb.png

 

Screenshot 2 - Lifecycle Mapping

 

ootb life cycle mapping for server.png

 

  • 1,382 Views
3 REPLIES 3

Nick Hynes
Tera Contributor

‎11-22-2023 07:03 AM

Hi there

 

We have also noticed this issue.  We have been setting CI's (mainly servers) manually and automatically as End of Life > Retired but have discovered this is no longer a valid option.

 

We haven't found any documentation on the reason behind this change and how we should factor it into other policies which utilise that combination e.g. Discovery setting devices' install status to Retired, which then sets them to this combination due to the (still active) Life Cycle mapping.

0 Helpfuls

cragland
Tera Contributor

‎03-01-2024 02:03 PM

Me too. 

0 Helpfuls

PG2
Tera Expert

‎03-03-2024 06:43 PM

To close the loop on this one and maybe help others. We decided to align with the documentation which means that we now have two retirement definitions. We have 'End of Life/Retired' for logical CIs and 'End of Life / Disposed' for Hardware CIs (which also comprises of virtualised hardware infrastructure.

 

We also learnt that we can handle the two definitions by activating the CMDB Retirement Definitions.

 

Some key lessons learned include:

 

1. It's important to get the legacy install status, hardware status and operational status values in sync even if you haven't historically used them before (the OOTB 'Sync Op Status for CMDB CI' BR will cause some issues if you don't).

2. It's ok to have multiple reverse mappings for a given lifecycle stage and status provided the legacy status is different. Doing this ensures that all status values remain in sync even if data manager is primarily concerned with updating the lifecycle stage and status. Another thing to note is that the CMDB Retirement Definitions might also be the place for this. We just couldn't get it to work.

3. The OOTB Lifecycle Mappings have some gaps in it and it doesn't align with the documentation. I'd suggest tailoring the mappings to your organisation and its historical use of legacy status values.

4. Hope for the best 😉 I've personally come to the realisation that this functionality is evolving quite a bit, so I've come to terms with the fact that some decisions and their outcomes are a bit of an unknown. We've been very conscious about not adjusting OOTB functionality.