rust-firecracker/fctools

Decisions pending feedback

Opened this issue · 1 comments

kanpov commented

Some controversial-ish design decisions I've made with the fctools API. I'd like some feedback from users about whether these decisions affect their DX and how. This is to prepare for a 1.0 release where these decisions are finalized:

  1. Dependency on nix crate. nix is not an internal dependency, it leaks out into public API with its Uid and Gid newtypes as of 0.5
  2. Very limited (if any) support for dynamic dispatch. With #3, the vast majority of traits in the public API except for CommandModifier which is stored in a Vec<Box<dyn CommandModifier>> are now fully incompatible with dyn. For me, this is inconsequential and provides benefits by not having to run proc macros on impls of these traits, as well as reducing runtime overhead associated with future boxing, but that may not be the case for others.
  3. Ownership limitations. Ownership is the major friction point of Firecracker SDKs, to which there are two solutions: pretend it doesn't exist (see Go SDK) or support the subset of ownership cases that makes maintainers (me) still stay sane. I've chosen the latter and 4 models are supported, which are implemented very well but do not support the "omnipresent host agent god" use-case, where 1 control process running as user A observes jailed VMs that each have a separate non-root user, i.e. B, C, D, E, F etc. Is it necessary for end-users to have this support or is the solution of 1 control process per such user attainable via fork()+setuid()?
kanpov commented

nix dependency problem has been basically resolved by having a choice between nix (libc wrapped syscalls) and rustix (direct syscalls) via removing sys-nix default feature. The Uid and Gid no longer leak into public API, u32s are used instead.