Spin CUD management and tracking into a separate module

Problem

The CUD provides a good format to describe what changes should ideally be made to configuration. However, it's currently tied to the update_helper module. This can cause issues when other modules try to create CUD files or apply the changes that are described within them.

An example is the work being done in #3097142: Make Update Helper work as source for the Config Distro module for the config_distro module to provide users with another way to managed configuration updates (sourced from CUDs) are applied. When a user moves between the update_helper and config_distro module in such a scenario it's easy for CUDs to be applied multiple times.

It's also conceivable that CUDs are generated from different sources such as a git diff.

Proposed Solution

Move the logic for storing, tracking and loading the CUDs into a separate module.

A config_update_definition module can be created that contains the code to serialize/deserialize the CUD to/from storage. Additionally it would contain methods that allow a CUD to be marked as applied. The module can also be responsible for enforcing the data integrity of CUDs. This ensures that CUDs can be created and consumed by different modules to suit different workflows.

The update_helper module would communicate with the config_update_definition module to write new CUDs to disk. Update hook implementations would then check with the config_update_definition to load the CUD and then apply it, marking them as applied in the config_update_definition module.

The config_distro module would ask the config_update_definition module for all unapplied CUDs, apply them and mark them as applied.

A theoretical git_cud_creation module could use the output of git diff on configuration files to create CUDs that could be applied by either config_distro or update_helper module as desired.

The decoupling between manipulation of CUDs and producers/consumers also ensures that storage methods can be changed transparently or even versioned if changes to the CUD format need to be made.

Todo

• Check out the Varbase distribution which has enhanced the Checklist module for better tracking of applied CUDs