Skip to content

runtime: hard-code Firecracker API socket path #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 19, 2019

Conversation

samuelkarp
Copy link
Contributor

Issue #, if available:
#59

Description of changes:
The Firecracker API socket is important for the runtime, as it uses the socket to communicate with Firecracker. Allowing the runtime to fully control the API socket (including its path) removes a potential failure condition from misconfiguration.

The API socket is hard-coded to exist within the current working directory. Part of the contract that containerd exposes for runtimes is that they are started with the current working directory changed to be that of the OCI bundle. Using an API socket in the OCI bundle makes its location well-known and predictable to the runtime.

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

The Firecracker API socket is important for the runtime, as it uses the
socket to communicate with Firecracker.  Allowing the runtime to fully
control the API socket (including its path) removes a potential failure
condition from misconfiguration.

The API socket is hard-coded to exist within the current working
directory.  Part of the contract that containerd exposes for runtimes is
that they are started with the current working directory changed to be
that of the OCI bundle.  Using an API socket in the OCI bundle makes its
location well-known and predictable to the runtime.

Related: firecracker-microvm#59
Related: firecracker-microvm/firecracker-go-sdk#88

Signed-off-by: Samuel Karp <[email protected]>
@samuelkarp samuelkarp requested review from nmeyerhans and mxpv March 19, 2019 21:46
@mxpv
Copy link
Contributor

mxpv commented Mar 19, 2019

Would this require us to have separate runtime instance per microVM?

@samuelkarp
Copy link
Contributor Author

It does right now, as that's the way the runtime works today. I know that we're thinking about changing the way the runtime works, but we don't yet know fully what we plan to do. I think having the socket path defined in the global config file is bad as it makes it too easy to misconfigure and conflict. If we do decide to have a single runtime, we can revisit this then and add it to whatever API is used to configure the runtime rather than a global config file.

@samuelkarp samuelkarp merged commit 25b61de into firecracker-microvm:master Mar 19, 2019
@samuelkarp samuelkarp deleted the socket-path branch March 19, 2019 23:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants