RFC: add containerName selector

[fewdan]

Summary

Add a new type of selector, namely "containerName selector".

Motivation

At present, some chaos involve containers (such as container-kill). If only the current selector is used, it is possible that the required container does not exist in the target pod.

Detailed design

We can add a type to the selector so that we can select pods with a specified container name.

Drawbacks

It may not be necessary enough.

Alternatives

Using existing options can solve the problem, but it is more troublesome for users. They need to know which containers exist in which pods.

Unresolved questions

None.

[STRRL]

What's the expected behavior of this selector? Could you provide some examples? 😁

[fewdan]

What's the expected behavior of this selector? Could you provide some examples? 😁

For example, if we specify containerName as "AAA", then all selected pods should have corresponding containers "AAA".

[YangKeao]

I think we need a more higher level design than simply add a field to the selector. Because it would be awkward for those Chaos who cannot be applied to a single container.

I have thought about the design of selectors and the development of chaos. Here is a draft:

Auto implement applyAllPods or something similar

The selector could have multiple different granularity about the target they select. For now, we only support two different granularity. They are pods and containers. For the convenience and compatibility, we can regard every pods selector as a containers selector (which selects the first container of each pods (though, selecting every containers should be better)).

To implement the chaos, the executor should provide at least one of the following two functions:

func ApplyAll() error
func Apply(index int) error

For those executor who implements Apply, the framework should iterate over all selected targets (no matter they are pods or containers) and pass it to the Apply function.

Auto select

Auto detect the selector fields in the specification and select them and add theses results to the status. For example, some network chaos may have two selectors: from and target. The selecting result should be added to the status (or something else to pass to the executor).

They are only a sudden thought 😿 , so feel free to ignore them or give a better solution.

[fewdan]

Auto select

Auto detect the selector fields in the specification and select them and add theses results to the status. For example, some network chaos may have two selectors: from and target. The selecting result should be added to the status (or something else to pass to the executor).

They are only a sudden thought 😿 , so feel free to ignore them or give a better solution.

Can I understand it like this, that is, after we select a target, we can achieve a universal apply func (pod or container can be accepted)?

[YangKeao]

Auto select

Auto detect the selector fields in the specification and select them and add theses results to the status. For example, some network chaos may have two selectors: from and target. The selecting result should be added to the status (or something else to pass to the executor).
They are only a sudden thought crying_cat_face , so feel free to ignore them or give a better solution.

Can I understand it like this, that is, after we select a target, we can achieve a universal apply func (pod or container can be accepted)?

For those chaos who can be applied on containers, we should always pass it containers. And for those who cannot be applied on containers separately, passing containers to them should result in an error.