Continuum currently uses Ansible playbooks that differ mainly in the target hosts (base, cloud controller, edge worker, etc.), while sharing substantial overlapping logic (e.g., regarding packages, kernel modules, sysctls, swap handling, Kubernetes repo setup). This leads to duplication between notebooks that complicates maintainability, where fixes have to be applied across multiple notebooks.
An Ansible role groups tasks and handlers related to a single concern (e.g., "Kubernetes prerequisites", or "container runtime setup") into a dedicated file that can be reused across multiple playbooks. Playbooks then only focus on picking roles and hosts, while roles detail the implementation via tasks.
For Continuum, this would significantly simplify the many Kubernetes-based installations (KubeEdge, Kubernetes, Kubecontrol, KubeKata). This results in improved maintainability, separation of concerns, better scalability, and cleaner reviews and debugging.
Rules should not be used for playbooks that are already small or for tasks that are unique to one notebook. There is no benefit to maintainability in these cases, you are only adding more layers.
To address this issue, incrementally introduce roles for the most commonly shared components (e.g., k8s_prereqs, k8s_repo, container_runtime), without changing behavior. Existing playbooks can then be simplified to role composition.
Continuum currently uses Ansible playbooks that differ mainly in the target hosts (base, cloud controller, edge worker, etc.), while sharing substantial overlapping logic (e.g., regarding packages, kernel modules, sysctls, swap handling, Kubernetes repo setup). This leads to duplication between notebooks that complicates maintainability, where fixes have to be applied across multiple notebooks.
An Ansible role groups tasks and handlers related to a single concern (e.g., "Kubernetes prerequisites", or "container runtime setup") into a dedicated file that can be reused across multiple playbooks. Playbooks then only focus on picking roles and hosts, while roles detail the implementation via tasks.
For Continuum, this would significantly simplify the many Kubernetes-based installations (KubeEdge, Kubernetes, Kubecontrol, KubeKata). This results in improved maintainability, separation of concerns, better scalability, and cleaner reviews and debugging.
Rules should not be used for playbooks that are already small or for tasks that are unique to one notebook. There is no benefit to maintainability in these cases, you are only adding more layers.
To address this issue, incrementally introduce roles for the most commonly shared components (e.g., k8s_prereqs, k8s_repo, container_runtime), without changing behavior. Existing playbooks can then be simplified to role composition.