Experiments for CloudNativePG project

[gbartolini]

Hi there,

I am a maintainer of the CloudNativePG project in the CNCF Sandbox. We are currently mentoring @XploY04 for a chaos testing project through the Linux Foundation/CNCF, and we would like to get your feedback about the best approach to follow.

Our operator defines a custom resource called Cluster, and doesn't use either a deployment or a statefulset standard resource (we directly manage PVCs). Our pods, like all the other resources created by it, are owned by the Cluster resource.

Given that our CloudNativePG clusters are made of a primary and an optional number of standby servers (replicas), we need to create an experiment that targets only the current primary of a cluster, identified by the cnpg.io/instanceRole=primary label.

We were wondering if it makes sense for @XploY04 to either submit a PR to enable customisation of the app kind to target also specific pods with labels, or to create a specific experiment like the Cassandra one.

Thanks for your feedback and cooperation.

[XploY04]

Hello,

To expand on what @gbartolini mentioned regarding the customization of label selectors when using [AppKind="pod"](https://github.com/litmuschaos/litmus-go/blob/ed4941327a694a7fdbe88b910d343f343751d289/pkg/utils/common/pods.go#L290): although this AppKind is not currently documented as supported in the [LitmusChaos documentation](https://litmuschaos.github.io/litmus/experiments/concepts/chaos-resources/chaos-engine/application-details/), I’ve been able to use it successfully.

At the moment, this approach requires specifying the TARGET_PODS environment variable with explicit pod names. Our goal is to extend this functionality to allow targeting pods via label selectors instead. This would be especially useful for cases like CloudNativePG, where we want to target only the current primary pod—identified by the label cnpg.io/instanceRole=primary.

I plan to implement this by modifying the logic [here](

litmus-go/pkg/utils/common/pods.go

Lines 281 to 283 in ed49413

	if len(chaosDetails.AppDetail) == 1 && chaosDetails.AppDetail[0].Kind == "KIND" {
	// select random pod from ns
	pods, err := FilterNonChaosPods(chaosDetails.AppDetail[0].Namespace, "", clients, chaosDetails)

) as follows:

if len(chaosDetails.AppDetail) == 1 &&
   (chaosDetails.AppDetail[0].Kind == "pod" || chaosDetails.AppDetail[0].Kind == "") {

    var labelSelector string
    if len(chaosDetails.AppDetail[0].Labels) > 0 {
        labelSelector = chaosDetails.AppDetail[0].Labels[0]
    }

    pods, err := FilterNonChaosPods(chaosDetails.AppDetail[0].Namespace, labelSelector, clients, chaosDetails)
    ...
}

This would allow the experiment to dynamically select pods based on labels when AppKind="pod", removing the need to manually specify TARGET_PODS.

We’d appreciate your thoughts on whether this should be submitted as a general enhancement to support label-based pod selection under AppKind="pod", or if it would be more appropriate to develop a dedicated experiment (as done for Cassandra).

Looking forward to your feedback.

Best regards,
@XploY04

[XploY04]

Update to my previous comment:

I've successfully used AppKind: "cluster" and it works well. However, I've observed that when there are more than 2 appLabels, the experiment filters target pods by each appLabel individually and then takes the union of all matching pods.

Questions:

1. Is this union behavior intentional?

2. I couldn't find any documentation covering:

   • The ability to use AppKind: "cluster"
   • How multiple appLabels are processed (union vs intersection)

   Will this be documented in an upcoming release?

Feature Request:

We would like to request a feature that allows taking the intersection of pods instead of the union when multiple appLabels are specified. This would enable more precise targeting by selecting only pods that match ALL specified labels simultaneously.

Thank you for your consideration!