This is a POC for using JIRA as a CMDB

 

An Issue is a "Configuration" item like a server, laptop, MySQL Database etc.

Why?

 

Well, most of the (seen from a ITIL Service Operation view) data is actually in JIRA, this is Incidents, Changes and Service Requests...

Secondly, JIRA can be seen as a mere Form/workflow control system

 

 

Architechture

Data validity, quality and maintenance

JIRA has strict fields

JIRA has versioning on all field changes (history)

JIRA field can by updated by GUI and programmatically (CLI, RCP, SOAP)

Tabbed input:

Fields / Links to Configuration Items from/to other JIRA Issues - Hostname lookup on the Summary field works

an alternative to linking could be a (multi)select field on issues in JIRA - like Kepler DB Lookup - https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.databasecf

Or: https://marketplace.atlassian.com/plugins/com.consultingtoolsmiths.jira.plugins.createandlink

Data out

Data can be extracted/fed out via:

 

JIRA XML/RSS Feeds

Atlassian CLI

SQL Quiries

Simplifying data from scripts

Field-values updated via CLI:

jira.sh --action setFieldValue --issue "CMDB-4" --field "Memory" --values "1024 MB"
jira.sh --action setFieldValue --issue "CMDB-4" --field "VM Version" --values "9"

The CLI only supports updating 2 fields in one call, hence 4 field will required 2 calls - and (possible) 2 notifications fired

 

Sanity Checks

We want to make a reverse check to make sure data is sane:

  • Is Virtual Center attributes aligned with JIRA State ?
  • Er der NetVault eller rsync data - i forhold til objektets servicemål/state
  • Is Monitoring data correct with Virtual Center Tags
  • Is the server in the Financial systems (for invoicing)
  • Is monitoring data coffect with monitoring system

Rapporting

Watchers on the Configuration Item (Issue)

Daily summary: https://confluence.atlassian.com/display/JIRA/Receiving+a+Daily+Summary+of+Updated+Issues

Screenshots

Dashboard

Configuration Item (sample for a server)

Links to events / tasks / incidents:

Virtual Center Data:

Service / Support data:

   

Monitoreringdata:

Workflow/Lifecycle

A server (or other Configuration Item) can have a controlled lifecycle (implemented as a workflow):

Challenges

Issues kan have server/object-name as Ident

Summary can be non-unique (e.g. 2 Configuration Items with same name can be created) 

Does not work: issuetype=server and (Memory changed after startOfWeek("-1") before startOfWeek())"

Screenshots

Tests

Updating field(s) with no changes:

spiderman:atlassian-cli npn$ ./change-serverfields.sh 
There are no field values changed by the parameters specified. Issue CMDB-4 not changed.
spiderman:atlassian-cli npn$

Hence, the CLI/JIRA takes care of changes and ignores no changes.

 

Updating field(s) with changes;

spiderman:atlassian-cli npn$ ./change-serverfields.sh 
Issue CMDB-4 updated.
spiderman:atlassian-cli npn$

Hence, the issue is updated.

Ideas

Metadaa

  • Scan servers for all *.sh and *.log files and save in JIRA field - for reference/documentation/searchability
  • Save crontab for all servers in JIRA field - for reference/documentation/searchability

Script information

Its an option to put more control into the update-scripts:

This introduces added complexibility and logic outside JIRA.

 

Flow for updating every value:

Sider med lignende indhold (Related Content)