To make a shift from EBPF to CO-RE BPF we need to migrate most of the existing
users of the former to the latter, without actually removing the EBPF
collection method as an option (because there still would be some usage of
EBPF, and removing it will also break OLM installations).
As far as I understand, there are following cases:
-
Update of an operator installation. There should be a possibility to execute some
custom logic to switch the collection method.
-
Update of a helm installation. Configuration is stored in the db.
-
Any new installation. Simply switch the default collection method (as it was
done for kernel modules -> ebpf).
One option would be to make Collector itself more responsible for a default
collection method (unless other options are enforced), but it will make
transparency worse.
Relevant experience from kernel modules migration:
stackrox/stackrox#5874
stackrox/stackrox#6797
stackrox/stackrox#6800
stackrox/stackrox#2104
stackrox/stackrox@bf283ed
Part of #1426
To make a shift from EBPF to CO-RE BPF we need to migrate most of the existing
users of the former to the latter, without actually removing the EBPF
collection method as an option (because there still would be some usage of
EBPF, and removing it will also break OLM installations).
As far as I understand, there are following cases:
Update of an operator installation. There should be a possibility to execute some
custom logic to switch the collection method.
Update of a helm installation. Configuration is stored in the db.
Any new installation. Simply switch the default collection method (as it was
done for kernel modules -> ebpf).
One option would be to make Collector itself more responsible for a default
collection method (unless other options are enforced), but it will make
transparency worse.
Relevant experience from kernel modules migration:
stackrox/stackrox#5874
stackrox/stackrox#6797
stackrox/stackrox#6800
stackrox/stackrox#2104
stackrox/stackrox@bf283ed
Part of #1426