firecracker-containerd icon indicating copy to clipboard operation
firecracker-containerd copied to clipboard

Remote labels

Open Kern-- opened this issue 3 years ago • 1 comments

Previously, the demux-snapshotter had to make an http request to the http-address-resolver to find the vsock address and metrics configuration for a remote snapshotter. With this change, the http-address-resolver is removed and this information is sent to the demux-snapshotter via snapshot labels directly from the client.

The labels are sent to the demux-snapshotter in the first pepare call at which point the demux-snapshotter will establish connection with the remote snapshotter. The connection is then cached via the namespace key as it was in the previous implementation for subsequent calls.

Since each microVM houses its own remote snapshotter in a clean slate on boot, any snapshot API call before a prepare will be operating on an empty snapshotter and therefore will be a noop/not found. Therefore, if we don't have a connection for an API, we can treat it as the noop/not found case.


I would like feedback on the idea here. There's a lot to cleanup including:

  1. Tests for the new pieces
  2. Setting up the eviction policy without a hardcoded port
  3. Removal of dead code (e.g. address resolver config)
  4. General cleanup/comments

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Kern-- avatar Jul 18 '22 22:07 Kern--

The role of the first Prepare() request is a bit concerning. We are assuming some order of calls which is less explicit than what we have currently.

If a caller violates the assumption, how does that work? Just return NotFound? Would it return something more specific? I still think the benefits of having less code/components is more worth than the risk of having cryptic errors though.

kzys avatar Jul 21 '22 18:07 kzys