Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
I do not have names on specific commentors. These notes have been re-ordered to make a bit more sense.
We have dynamic environments, with information coming from systems and builds.
Systems need configuration from runtime data based on service discovery and build configuration (IP addresses, versions, etc).
CMDB use contexts:
On call users - The sysadmin who has been paged at 4 am needs to determine context for the page.
Deployment systems - To know where to deploy software, what version(s) to deploy, etc.
Maintenance - Downtimes, escalate, software versions, hardware info...
Management - Reports
Auditors - Licensing, security, change control, etc
Provisioning systems - To actually provision VMs/hardware
Configuration Management Software
See PuppetDB for a good example of separate storage and API.
A CMDB should provide history.
Context can be things like system performance after rollouts, last n tickets, changelog for a rollout, etc
Limiting yourself to only current state is not good
We should be able to determine variability in systems
Not everyone needs access to context all the time. Too much context is noise, too little context ends up with human spending time in context discovery
A CMDB should be able to verify and validate data
This is needed to support audits, etc
Excel is a popular reporting system, but we do not want to use Excel as a frontend.
Autodiscovery is a useful feature, but daily or weekly discovery is not fast enough today.
Version control hooks are good.
Version control hooks which update/close tickets are fantastic. Well written commit messages assist in helping people determine context, act as documentation and assist in building a story about the system.
CMDB users are mainly other computers, rather than other people.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment