Maksym Pavlenko

Hey. Thanks for opening this. `creating new VM ` comes from our runtime. As far as I see currently `containerd` doesn't pass log level to shims (see [1](https://github.com/containerd/containerd/blob/97ca1be06752cf220f1fa91ae8ececa0461dc284/runtime/v2/shim/shim.go#L100), [2](https://github.com/containerd/containerd/blob/97ca1be06752cf220f1fa91ae8ececa0461dc284/runtime/v2/shim/shim.go#L128) and...

FC's `Running` state doesn't guaranty that Agent is initialized and ready to serve requests. So option 3 adds 2 kinds of retry: wait for FC API available / state=Running, and...

What are benefits of adding one more retry logic? I would rather vote for option 1 :)

The reason I vote for option 1 is simplicity. It's just dials with retries. Option 3 adds extra complexity while benefits are a bit blurred for me. But I agree...

Option 4: make agent responsible for initial dialing to runtime (e.g. Runtime runs a listener, runs a VM and waits for Agent to connect, and after accepting a request Runtime...

I've no idea hot to fix Fuzzing stuff :( This was introduced in https://github.com/containerd/containerd/pull/7052 @AdamKorcz any ideas?

@mikebrow this PR replaces entire image store with a set of labels assigned to `Image` (so it's already decoupled). Moving some labels elsewhere would be super straightforward.

Rebased against `main` to apply fix for Fuzz CI

@mikebrow I wrote a quick benchmark to get order of numbers. 30,000 images, 3 references per image (so 90.000 metadata image records in boltdb), takes ~2 seconds on MBP 2019....

@dmcgowan I haven't put much though into it, we can bring this on the next community call. I'd like to learn more about potential use cases of this. Labels are...