[TechDebt] Refactor AbstractDeploymentManager: Decomposing the God Class via the Strategy and Delegation Patterns

[oleksii-donets]

Name and Version

0.14.0

What is the problem this feature will solve?

The AbstractDeploymentManager has evolved into a classic "God Class," absorbing too many distinct responsibilities and violating the Single Responsibility Principle (SRP).

Specifically, the current implementation suffers from the following architectural issues:

Lack of Cohesion: The class mixes high-level deployment orchestration (transactions, rollbacks, database status updates) with low-level, domain-specific operations.

Multiple Reasons to Change: A change in how Cilium network policies are labeled, a tweak to how Kubernetes pod container termination statuses are parsed, or a new requirement for fetching log resources will all force modifications to this single core file.

Dependency Bloat: The class requires an ever-growing list of injected dependencies (e.g., CiliumNetworkPolicyCreator, ManifestGenerator, DisposableResourceManager), which makes subclassing and unit testing extremely cumbersome.

Leaky Abstractions: Deeply nested private helper methods for Kubernetes object parsing (extractContainerInfo, getTerminatedState, describeContainerState) clutter the class and hide the primary orchestration logic.

What is the feature you are proposing to solve the problem?

I propose refactoring AbstractDeploymentManager to act purely as a high-level Orchestrator/Facade. We will strip out the implementation details of peripheral domains and delegate them to newly created, specialized service classes.

Here is the proposed decomposition strategy:

1. Extract KubernetesSecretManager
   Action: Move provisionSecrets, cleanupSecrets, resolveSecrets, and transformEnvs out of the deployment manager.

Responsibility: Solely handles the translation of application EnvVar models into Fabric8 Secret manifests, interacting with the K8sClient and DisposableResourceManager.

2. Extract PodStatusInspector (or InstanceHealthService)
   Action: Move getActiveInstances, getInstances, toPodInfo, extractContainerInfo, and the complex termination state comparison logic (getLaterTermination, getTerminatedState).

Responsibility: Encapsulates all the Fabric8-specific boilerplate required to inspect PodStatus, ContainerState, and calculate restart counts or exit codes.

3. Extract DeploymentLogResolver
   Action: Move getContainerResourceForLogs, assertContainerLoggable, findContainerStatus, and assertPreviousLogsAvailable.

Responsibility: Handles the specific business logic and validation required to safely stream or retrieve logs from a given container state.

4. Extract NetworkPolicyHandler
   Action: Move all Cilium-related methods (createCiliumNetworkPolicy, updateCiliumNetworkPolicy, deleteCiliumNetworkPolicy, getCiliumIngressPorts).

Responsibility: Manages the lifecycle of CiliumNetworkPolicy resources tied to deployments.

End State of AbstractDeploymentManager
Once refactored, the AbstractDeploymentManager will only retain its core lifecycle template methods (deploy, undeploy, rollingUpdate, reconcile) and its abstract contracts. It will inject these new specialized components to handle the heavy lifting, drastically reducing its line count, simplifying unit tests, and establishing a cleaner architectural boundary.

What alternatives have you considered?

No response