Which table to be used for CI status updates

[Hanumant Madan1]

Dear All,

I have one ask from client, I am wondering which table I should be creating this BR on: cmdb_ci or cmdb_ci_hardware.

Rule needed for the following:

If the Status(install_status) = Absent, Retired or In Stock then the Operational Status should = Non-operational

If the Status(install_status) = Installed then the Operational Status should = Operational

The Operational Status supports the CMDB Health Score Card and CSDM metrics.

Also, I will need to run fix script to run for updating all the records as per above situation, so need suggestion on which table this values should be updated as a best/standard  practice.

Help is appreciated.

Regards,

Hanumant

[ersureshbe]

Hi, 

Do you have equivalent asset for each ci then you should write the script based in hardware table

else you should write the code based on cmdb_ci table.

Please mark as correct answer if it helped.

Regards,

Suresh,

[CMDB Whisperer]

I would not advise this as it oversimplifies things a bit.  Operational status tells us whether the item is "operational" or not.  Something that is Installed but experiencing an outage is not Operational.  Operational status of something that is not Installed may be subjective.  Is it defective, pending repairs, etc.?  CSDM Lifecycle Stage/Status is probably a better thing to define your health metrics on.  I would recommend opting into CSDM Lifecycle and then looking at mapping your values if applicable, rather than trying to mess around with your existing statuses.  Note that these values aren't set by users directly and should not be added to forms.  They are set based on enabling the mappings from the status fields you are already using.

[Hanumant Madan1]

is it not a good idea if CI is Status(install_status) = Absent, Retired or In Stock then the we move the  Operational Status to Non-operational?

how should we handle this in general? via CSDM only?

Regards,

Hanumant

[CMDB Whisperer]

It's understandable that you might want to do that, but if so that might make sense more at the transition point of the status rather than as a Fix Script.  None of this is written in stone, and certainly customers do have different perspectives and practices here, so there is inherently some subjectivity but the desire is to move toward consistent practices for managing lifecycles.  That said here is what I would suggest considering:

• If something is Absent, in general that means we don't really know what its status is.  From a Discovery perspective this could just mean that it wasn't included in the last scan, which could be a temporary condition.  Maybe Non-operational makes sense here?  An argument could be made either way.
• If something is Retired, this might NOT mean it is non-operational.  Perhaps it is being retired because it is still functional but no longer meets the required use of the services that have depended on it.  It could potentially be put back into stock for reuse by another party.
• If something is In Stock, is it operational or not?  Is it worth tracking this on a CI level?  Often we don't think about tracking CIs for assets that are In Stock because they don't meet the theoretical definition of a CI (a deployed asset) but in reality it's not really that cut and dry.  For instance, if you have Loaner laptop, you will return them back into stock every time they are returned, but the CI still lives on between active assignments, so we might want to be able to track the difference between a Loaner laptop that is Operational (i.e. ready to be loaned out) and one that is Non-Operational (i.e. Pending Repair).

As you can see, it's still a bit subjective, but I think the more we can clarify the difference in usage and meaning between Install Status and Operational Status the better off we'll be.  And to me that means that since Operational Status is not actually part of the synchronization between Asset and CI, it should not be further leveraged as a critical part of the lifecycle transitions, but be used more informationally.  Even the CSDM Lifecycle is not perfect, but it's much more consistent, so my recommendation is that if you are going to base anything like metrics on something solid, you might want to consider implementing them now, as it will be more likely to be compatible with future releases.