Documentation / Examples / Future Prospects

[nickheyer]

First, let me say thank you for filling a void where there shouldve been a Rust SDK for Firecracker (a rust application...). It's not an easy task, im sure.

Given that this is the only one that seems to be actively maintained, I would like to give you my perspective as someone looking to "embed" firecracker within my rust application.

1. Creating and working on your own tickets/issue tracker gives me confidence in the future maintenance of this project.
2. I think there is a serious need for documentation and example usages of this library. Thinking of a "simple" use-case, like provisioning/spinning-up a vm and echoing "hello world".
3. You've created a solid foundation, but you could be even more ambitious with the help of contributors. Creating some solid contribution guidelines, how to get started contributing, etc.
4. Ironic, but the most actively maintained SDK is for Go. I think you could potentially draw a lot of inspiration there in regards to at least base line functionality. Granted, I haven't really checked it out.

So all that being said, thank you again for taking the time to maintain this! The application I plan to implement this in was previously targeting Microsoft's new "micro vm" project called "Hyperlight" which actually requires embedding via Rust - but it turned out to be incredibly restrictive given the lack of stdlib.

[kanpov]

Thanks for the time! The immediate state of the project is that 0.5 is recommended for any new applications, but it's still in RC stage since I'm not sure I'm done with the breaking changes.

For documentation, I will certainly work on that as soon as 0.5 releases with some examples. For the time being, test_framework.rs has test infrastructure for the entire project so that should generally be good enough to get started.

For contribution guidelines and so on, I'd love to as soon as I'm done with 0.5 once again. It should be easy enough, except for CI - the current test suite requires a bare metal 8+ core Linux machine with KVM and root access, so getting the tests to run automatically would not fall in the type of expenses I can cover unfortunately. It is runnable on any workstation with those requirements though, provided you copy testdata blobs to /opt/testdata.

Lastly, the Go SDK I have looked at, but, in spite of it actively being maintained, it is in a very poor state in comparison to what fctools can deliver even as a one-person project:

• Not updated for Firecracker 1.5+
• Has not had a release since 2022
• Does not support extension features that fctools has: gRPC/vsock, HTTP/vsock, link-local IPv4 subnet allocation, background metrics collection, snapshot-editor invocations
• Does not support ownership models (i.e. assumes shared ownership), which is pretty much the most massive problem with developing a Firecracker SDK
• Not sure if it supports --new-pid-ns, which was quite the journey to implement (#4) for me
• Does not map out to all modern CLI argument for both jailer and firecracker

And there's a lot more that I could probably find. It's a shame that the Go SDK doesn't seem to be getting a lot of love.

[kanpov]

And another thing, the "full" stack that I made consists of not only fctools, but also fcnet and co. for networking (even though I wrote an async Rust CNI runtime, I still don't like tc-redirect-tap that the Go SDK uses at all) and buildfs

[nickheyer]

And another thing, the "full" stack that I made consists of not only fctools, but also fcnet and co. for networking (even though I wrote an async Rust CNI runtime, I still don't like tc-redirect-tap that the Go SDK uses at all) and buildfs

I think you echo a lot of the same sentiments that others are feeling, which is why this is certainly a contender for mass adoption. I actually tried building a proof of concept with it last night.

For example, the tc-redirect-tap (and it's additional CNI plugins) currently do not work if you were to build both as they imply you should (then make accessible to your app at runtime). There is a bunch of version mismatching (or simply undefined versions), and the only way I was able to get it working was to dive into the makefile they use in a ci workflow and replicate the commands they are using to build old version(s) of the plugin(s). So all that being said, I appreciate the alternative solution even more.

Buildfs is also an awesome idea and something that I may start using immediately. I wrote a bash script that does a pretty crude job using debian imager to bootstrap it, but I couldnt get something working quickly.

[kanpov]

@nickheyer 0.5 got released with major shutdown improvements that allow much better observability/diagnostics as well as failover plus timeout when shutting down a VM (with breaking changes, of course). As mentioned, I'm planning to pivot to work on the documentation after this release.