Feature Request: ChaosEngine to support multiple app labels

[litmuschaos]

Feature Request: ChaosEngine to support multiple app labels

[ksatchit]

As of today the target identification is done in two ways:

• (a) At a workload level (deploy/sts/ds/dc/argo rollouts) where the first level filter is done using a single app label & and a further subsequent filter by annotation in case where there are multiple workloads w/ the same label. It is possible for you to annotate more than one workload too if you would like random selection of pods from amongst a workload set.
  All this, only if the spec.annotationCheck is set to true in the chaosengine. The operator in this case passes the targeted workload name/kind details along with label/annotations to the respective experiment pod for actual chaos injection purposes.

• (b) At a pod level, where the target pods (workloads are out of the picture) are identified purely via label(s) provided in the .spec.appinfo.applabel. You can get a bit inventive here with the way labels are assigned. For example, something like: component in (litmusportal-frontend,litmusportal-server) where the key is common OR via key=value as a comma separated list.

In (b), the operator simply passes the string input in this field to the experiment pod - so it becomes similar to a kube-api/kubectl call with multiple labels in the --selector/-l flag. In (a) the filter logic extracts key/value via some parsing logic that doesn't recognize these multi-label patterns. The improvement needs to be made accordingly.

In both cases, there are additional ENV variable that the experiment takes which influence the eventual list of affected pods as well as the manner in which chaos is applied on them. They are:

• (i) PODS_AFFECTED_PERC: which controls the percentage of pods subjected to chaos from the filtered list. When targeting a single workload, it effectively becomes the no of app replicas affected. In cases where the filtered pod list is coming from diff workloads, there is a bit if randomness introduced.

• (ii) SEQUENCE: which controls if eventually selected pods are subject to chaos at once in parallel OR in a serial manner.
  Both (i) & (ii) are available in the native/off-the-shelf litmus experiments & may/may-not be present in your downstream experiments depending upon implementation.