[Feature] Enforcement

The basic premise of GitOps is to state that the known state is that which is stored in a Git repository, and that any deviation from that state is unwanted and to restore the state to what is represented in Git. This ideal state requires significant organization change and may ultimately be to rigid, causing non-compliance or impacting productivity.

To create a more flexible approach Arlon will have multiple modes for managing the how a cluster operates and what will happen when changes are made either to the profile and associated resources Git, or to the cluster's running state.

Enforcement:

When a user creates a cluster they should be able to specify if the cluster is going to be under one of three policies:

1. Enforced
2. Monitored or
3. Unmanaged

Enforced: This mode will cause any 'drift' to be automatically overwritten/restored back to the state declared in the Profile, Bundle and/or clusterSpec. An event is stored in Arlon for historic/audit capabilities and if elected a notification is send.

Monitored: Monitored acts as an overseer, looking for changes in Bundles, Profiles and clusterSpecs, when drift is detected an audit event is logged and if enabled, a notification send.

Unmanaged: No automated drift management will be active. Users can manually invoke a Diff Analysis

Changing Enforcement Modes

Once a cluster is built a user should be able to change the clusters specific enforcement mode, such that it can be changed in real time at any time. For example, 10 clusters are built using ClusterSpec Prod-A with the enforcement mode "enforced" and a user wants to test a change on only one of the clusters. The user changes the single clusters enforcement mode to "monitored" meaning that they can make changes and will receive email notifications of the non-compliance but the change will not be reverted. Once they are done testing the change the user updates the ClusterSpec Prod-A and synchronizes it to all 10 clusters. They then change the enforcement mode back.