Add support for Deployment into xtf API

[mchoma]

As stated e.g. in #579 OpenShift is marking DeploymentConfig for deprecated and recommends to switch to Deployment.

Unfortunatelly we do not have support for Deployment yet.

This issue is about adding such support. For now keep in mind backward compatibility. So user who are using by default DeploymentConfig should not notice change. It should be intended decision for callers to use Deployment instead of DeploymentConfig.

[mchoma]

@dosu what do you think how that could be implemented?

[dosubot]

To add Deployment support while keeping backward compatibility, you’d need to introduce new builder and orchestration logic for Kubernetes Deployments alongside the existing DeploymentConfig-based flow. The current codebase is tightly coupled to DeploymentConfig at all major layers—builders (like DeploymentConfigBuilder), aggregators (ApplicationBuilder, OpenShiftApplication), orchestration (OpenShift, OpenShiftWaiters), and even auxiliary interfaces and database abstractions. There’s no abstraction for generic workloads yet, so supporting both resources means either refactoring to a common interface or duplicating much of the builder and client logic for Deployments.

A practical approach would be to:

• Create DeploymentBuilder and related classes mirroring DeploymentConfigBuilder, but targeting apps/v1.Deployment.
• Extend ApplicationBuilder and OpenShiftApplication to manage both DeploymentConfig and Deployment resources, letting callers explicitly choose which to use.
• Update orchestration and waiter logic (like OpenShiftWaiters) to handle both resource types, possibly via a shared interface or branching logic.
• Mark DeploymentConfig-specific APIs as deprecated, but keep them as the default to avoid breaking existing users.

This would allow users to opt into Deployments explicitly, while existing code using DeploymentConfig continues to work as before. Significant refactoring is required, as the current architecture assumes only DeploymentConfig everywhere (see, for example, DeploymentConfigBuilder, ApplicationBuilder, and OpenShift.java). There’s no sign of a patch or prior implementation for this in the repo.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[mchoma]

@dosu It would be nice if we could get in future also support for other workloads as well, e.g. StatefulSet. That support would be nice in ApplicationBuilder and OpenShiftApplication. Therefore I like your idea of introducing some sort of abstraction (interface) covering generic workload. Could you elaborate a bit and propose some snippets how that could look like?

[dosubot]

A generic workload abstraction could look like a WorkloadBuilder interface with methods for setting replicas, strategy, and triggers—covering the common API surface for Deployment, DeploymentConfig, and StatefulSet. Each concrete builder (e.g., DeploymentConfigBuilder, DeploymentBuilder, StatefulSetBuilder) would implement this interface.

Example interface:

public interface WorkloadBuilder<T> {
    WorkloadBuilder<T> setReplicas(int replicas);
    WorkloadBuilder<T> setStrategy(String strategy); // e.g., "Rolling", "Recreate"
    WorkloadBuilder<T> addTrigger(Trigger trigger);  // Trigger could be an enum or class
    T build();
}

A concrete builder (e.g., for DeploymentConfig) would implement this:

public class DeploymentConfigBuilder extends AbstractBuilder<DeploymentConfig, DeploymentConfigBuilder>
        implements WorkloadBuilder<DeploymentConfig> {
    // ...existing fields and methods...
    @Override
    public DeploymentConfigBuilder setReplicas(int replicas) { /* ... */ }
    @Override
    public DeploymentConfigBuilder setStrategy(String strategy) { /* ... */ }
    @Override
    public DeploymentConfigBuilder addTrigger(Trigger trigger) { /* ... */ }
    @Override
    public DeploymentConfig build() { /* ... */ }
}

In ApplicationBuilder, you could maintain a set of WorkloadBuilder<?> instead of just DeploymentConfigBuilder, and expose methods to add or retrieve different workload types:

private final Set<WorkloadBuilder<?>> workloads = new HashSet<>();

public <T> WorkloadBuilder<T> workload(String name, WorkloadType type) {
    // Factory logic to return the right builder (Deployment, DeploymentConfig, StatefulSet)
}

OpenShiftApplication would then iterate over all built workloads and create them via the appropriate client method, allowing for future extensibility without breaking existing consumers.

This pattern lets you add support for new workload types (like StatefulSet) with minimal changes to the orchestration logic and keeps the API surface consistent for users. The builder pattern and abstraction fit well with the current codebase structure and would make future extensions straightforward.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.