add containerd annotation support for checkpoint metadata parsing

[slashexx]

Fixes #95

This PR adds a conditional check to check for containerd annotations and properly parse containerd annotations.

Previously, the operator used to silently skip containerd checkpointing by hitting a JSON unmarshal error on the empty io.kubernetes.cri-o.Labels annotations.

Annotation difference :

CRI-O stores metadata as a JSON blob inside a single annotation, which must be unmarshalled: so io.kubernetes.cri-o.Labels has JSON containing io.kubernetes.pod.namespace, io.kubernetes.pod.name, io.kubernetes.container.name etc.

On the other hand, containerd stores metadata as flat, individual annotations, in contrast to the single one. (io.kubernetes.cri.sandbox-namespace, io.kubernetes.cri.sandbox-name, io.kubernetes.cri.container-name)

For reference, I took a look at the source code https://github.com/cri-o/cri-o/blob/main/internal/annotations/annotations.go and here : https://github.com/containerd/containerd/blob/main/internal/cri/annotations/annotations.go

Before the fix

After fix

[slashexx]

@adrianreber ptal !

[slashexx]

@adrianreber @rst0git gentle ping, ptal once :)

[slashexx]

@adrianreber @rst0git gentle pinging once again

[adrianreber]

Does this work? Which annotations are used by containerd and which by CRI-O. Please mention that in the commit message and PR description. This sounds like you are just avoiding a crash, but isn't everything functioning correctly?

[slashexx]

@adrianreber yes I have tested this myself. The operator was parsing containerd metadata and applied policies correctly. I will add the annotation difference that I worked upon mostly.

This sounds like you are just avoiding a crash, but isn't everything functioning correctly?

To answer your question, if I understood it correctly, there was no crash in the first place. It was just silently failing to parse metadata and hence no retention policies were being applied.