The This is a POC for using JIRA as a CMDB

...

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

...

JIRA XML/RSS Feeds

Atlassian CLI

Simplificering af scripts

Ingen mellem Database lag hvor vi skal holde styr på States

Atlassian CLI til JIRA

SQL Quiries

Simplifying data from scripts

Field-values updated Field/Values opdateres samlet 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"

Sanity Checks

Jo flere datakilder, jo bedre mulighed for at køre sanity checks (Data korrekthed /integritet), f.eks:

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

• Is Virtual Center attributes aligned with Passer VC folder (produktion, other, disabled) med JIRA State ?
• Er der NetVault eller rsync data - i forhold til objektets servicemål/state
• Passer Zenoss Group (servicemål) med VC Data
• Passer Zenoss Data med objektets data
• Findes servernavn i Navision hvis Servicemål > Bronze?
• Har vi alle maskiner hvis Servicemål > Bronze i Zenoss?

Rapporting

• 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)Watchers for server changes

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

Screenshots

Dashboard

Configuration Item (sample for a server)

Link til opgaver/eventsLinks to events / tasks / incidents:

Virtual Center Data:

Service / Support data:

MonitoreringsbeskrivelseMonitoreringdata:

¨

Workflow/Lifecycle

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

Challenges

Issues kan have server/object-name as Ident

...

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

Screenshots

Test

Tests

Updating field(s) with no changesOpdatering af flere felter på en gang, hvor ingen er ændret (der understøttes kun 2 felter pr. gang):

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$

Altså kan man bare opdatere løs UDEN at bekymre sig om felterne faktisk er ændret 

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

Updating field(s) with changes;Opdatering af flere felter på en gang, hvor et af flere er ændret:

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

Ideer

Alle mulige metadaa

Hence, the issue is updated.

Ideas

Metadaa

• Scan servers for all Scan for alle *.sh og and *.log filer på et server - gemme i et felt for søgbarhed
• Gemme crontabs for alle servere

Notification

Da Notificationer i JIRA desværre ikke er pr. felt, men ved en update af et issue, kan det generere mange unødvendige mails; derfor er der flere alternativer til notifikation

Script information

Kontrol m.v. lægges ud i script:

Flow for opdatering af værdier; for hver Attribut (Indeholdende en VÆRDI)

Splunk Rapport

Da vi opsamler ændringer fra JIRA's "ChangeItems" Tabel, vil du også være muligt at lave en rapport i Splunk, der blot filtrerer på rettelser i visse felter i visse JIRA typer.

ChangeItems udtræk

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

Flow for updating every value: