f3ew · February 7, 2017 14:06
diff --git a/gistfile1.txt b/gistfile1.txt
 CMDB:
    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

 CMDBs need a REST API
    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.
	CMDB:
	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

	CMDBs need a REST API
	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.