firecracker-microvm / firecracker-microvm/firecracker-containerd

Consider supporting external container grouping OCI annotations

Open
#162 1 comment 0 reactions 0 assignees View on GitHub
area/runtime kind/enhancement
Dominant language
Go
Stars
2.9k
Forks
247
PR merge metrics
No merged PRs in 30d

Description

As mentioned in the comments on #160 we should consider whether we want to support the other OCI annotations that exist for grouping containers under a single shim or in a single sandbox in our own shim, for the purposes of grouping containers in a single firecracker VM.

* [Containerd PR that adds support in their runc shim for these groupings.](https://github.com/containerd/containerd/pull/3004)

Considerations:
On one hand, it would be nice to automatically group containers into VMs using these already defined annotations so users can switch to firecracker-containerd more seamlessly.

On the other hand, I don't know if we want to entangle ourselves and our users with keys that have meaning out of our control. I.e. what if some other random part of a user's stack starts also interpreting io.kubernetes.cri.sandbox-id or io.containerd.runc.v2.group but does something the user doesn't want? That user would probably prefer to just have a key like aws.firecracker.vm.id so they can specify the firecracker VM without any extra side-effects.

Maybe what'd be best is for our shim implementation to interpret each one with some priority, i.e. use aws.firecracker.vm.id if set, if not check io.kubernetes.cri.sandbox-id, if not check another, etc.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.