Hacker News Reader

Comment by wyldfire | Hacker News Reader

Gee, why not just go straight to step 3 via fork/exec? Bound to shave off a few milliseconds beyond that 10x. And no firecracker required.

View on HN

If you a cloud host, you need a way to sandbox hostile code. Firecracker allows you to do that (it is a configuration of the traditional KVM virtualization system except lighter and faster, instead of booting a VPS which can take minutes, you can now spawn one in under a second).

To clarify my post: I see the reason for Firecracker to exist in general, it's great. But does "e2e tests" include untrusted code? I think it really shouldn't.

So why use firecracker here? Invoking your tests in a bare VM or container is great for making sure that you are controlling the environment and enumerating your system dependencies. But this post proposes discarding those things and instead using some saved state as the entry point into your Firecracker. So now you are booting from Your Image instead of a { Official Distro Image + Dependency Recipe }. It seems like a step backward.

The company that wrote the article is a e2e testing cloud hosting company that runs your code in their cloud.

Ah, then that's actually a pretty compelling use case. Not a "here's how you can do it" so much as a "here's how we did it (and kept you customers safe from the baddies)".

Author here!

I think there's always been a push/pull of "fat base images" versus "install everything every time" - It's obviously subjective, but I think it's more important to run the tests on every commit than it is to start the environment from scratch.

It's also not necessarily mutually exclusive, you could have a "staging branch" where you make something that looks a lot like production and then re-run end-to-end tests there, while running the per-branch tests with this method to avoid slowing down developers.

> But does "e2e tests" include untrusted code?

What other possible way could CI work?

Continuous integration can -- and does -- happen with local development teams using their own equipment. In general, those are typically pretty trusting environments where Firecracker style isolation is not as critical.

Not just sandboxing, but just ensuring that each test runs in a clean environment, without interference from files/processes left behind by a previous or even concurrent test.

Because process isolation under unix is pretty lax. Processes have by default have all the rights of the user. And you might end up with a system different from the initial state

Reply on news.ycombinator.com