Done When:

• CDM doesn't need to be disabled for OCL case

Notes:

• Config Drift Monitor use
  • Fsnotify is used to watch files for write events that the MCO manages
  • Any deviations detected will change the node to degraded instantly
  • Admin is told to resolve the issue to get state to match again
    • Revert manual changes
    • Or forcefully overwrite the contents
  • Early warning system
• How does config drift monitor fit into the OCL world
  • Continue having CDM validate against MCs created as it currently behaves
• Manual changes on node are usually for debugging purposes
  • Document that any changes in `/var` will persist across upgrades
  • Document that any changes in `/etc` will have a 3 way merge done it across upgrades
  • This is already the current behavior so should match expectations.
• Any config admin wants applied to cluster should always be done via MOSC and MC for OCL case
  • Custom changes will be included in the image built during the OCL process

From discussions, nothing needs to be done regarding Config Drift Monitor for OCL. What we need to think about it whether we need to add some form of image content validation mechanism to the MCO to do what the CDM does with on-disk and MC for on-disk and image content. This needs further discussion on whether this is even a problem we need to solve right now.

Some relevant issue links:

https://issues.redhat.com/browse/MCO-757

https://issues.redhat.com/browse/MCO-985 

https://issues.redhat.com/browse/OCPBUGS-18414