Using the new Operational / Pending Retirement Lifecycle Stage & State

[PG2]

I've started to use the new new 'Operational / Pending Retirement' Lifecycle Stage & State to reflect CIs that are being prepared for decommissioning.

I've noticed that any update to the CI in this state will retrigger the OOTB life cycle mapping rules and reset the Lifecycle Stage & State to 'Operational / In Use'.

With no equivalent legacy state for Pending Retirement on CIs outside of the cmdb_ci_service class hierarchy, how can we make use of this new Pending Retirement state without it being reset any time the CI is updated across any one of its attributes? 

Has anyone experienced this same issue? I've attached an example, explaining the above scenario.

[karthiknagaramu]

Hi,

One option it to probably add a condition in the 'Update life cycle from legacy' BR to not trigger for this situation.

Regards,

Karthik Nagaramu

[PG2]

Hi Karthik, thanks for the suggestion, but its probably best to avoid changing or updating OOTB BR's because of the unknown consequences and flow on effects.

[Tomas Lozano]

Hi PG2

Probably not the solution but how did you previously identify a CI that was pending for retirement?

If you've used a custom value, could you simply create the appropriate mapping in the CSDM lifecycle mapping (life_cycle_mapping) table?

If not, do you see any changes to the lifecycle mapping that could work? Short of creating the 'Pending Retirement' equivalent choice i'm not sure you should meddle with the BR's

Cheers,

Tomas

[PG2]

Hi Thomas,

Fortunately or Unfortunately (depending on which way you look at it), we never introduced a customised value.

And we didn't have a way to identify a CI as pending retirement. We've also been trying very hard to not introduce customised values. That's a mantra we're sticking too as we move towards consuming these new standardised lifecycle attributes.

We held off and even considered alternatives such as using the request to decommission a CI as context to indicate whether a CI is pending retirement (e.g. if a decom request is open, but not complete, then the CI is pending retirement).

It was great to see a new Pending Retirement lifecycle Stage/State because now it makes it easier to identify a CI in this state.

We're motivated to move to the new lifecycle stage & states for many reasons, and introducing new values in the legacy attributes isn't palatable because it contradicts our intent to move away from the legacy.

And unfortunately, I'm not seeing how any changes or adjustments to the lifecycle mapping can help, considering the existing OOTB BRs. 

It's a tricky one for sure!