Du ser en gammel version af denne side. Se den nuværende version.

Sammenlign med nuværende Vis sidehistorik

« Forrige Version 3 Næste »

This is a POC for using JIRA as a CMDB

 

Architechture

Architecture

Data validity and maintenance

JIRA has strict fields

JIRA has versioning on all field changes (history)

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):

Lifecycle

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:

Flow

  • Ingen etiketter