baskarp · February 14, 2017 15:56 · Feb 7, 2017
diff --git a/gistfile1.txt b/gistfile1.txt
@@ -0,0 +1,35 @@
+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.