This is a POC for using JIRA as a CMDB
An Issue is a "Configuration" item like a server, laptop, MySQL Database etc.
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
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)
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
Data can be extracted/fed out via:
JIRA XML/RSS Feeds
Simplifying data from scripts
Field-values updated via CLI:
The CLI only supports updating 2 fields in one call, hence 4 field will required 2 calls - and (possible) 2 notifications fired
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
Watchers on the Configuration Item (Issue)
Configuration Item (sample for a server)
Links to events / tasks / incidents:
Virtual Center Data:
Service / Support data:
A server (or other Configuration Item) can have a controlled lifecycle (implemented as a workflow):
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())"
Updating field(s) with no changes:
Hence, the CLI/JIRA takes care of changes and ignores no changes.
Updating field(s) with changes;
Hence, the issue is updated.
- 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
Its an option to put more control into the update-scripts:
This introduces added complexibility and logic outside JIRA.
Flow for updating every value: