-
Notifications
You must be signed in to change notification settings - Fork 200
Adding netns to jailer #305
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
6810029
to
a7af606
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something we need to think about: right now this doesn't really work with the CNI support. When the CNI support was originally added to the Go SDK, it was written such that:
- If a CNI network interface was provided for the VM, the netns specified in the
machine.JailerConfig
would be used unless one wasn't specified, in which case a new one would be created. - When starting a VM, if there was no
machine.JailerConfig
but a netns was specified (i.e. you are using a CNI interface but w/out JailerConfig being specified) then we just directly start the machine in the netns.
However, I just realized that the jailer support in firecracker-containerd actually doesn't use the machine.JailerCfg
field in the go sdk, it uses its own JailerConfig
that doesn't get translated to the go sdk's JailerCfg
. So right now I think weird things happen if you use a CNI interface w/ a firecracker-containerd JailerConfig
netns specified in CreateVM
:
- The netns specified in the CreateVM call will be set in the runc config, but the go sdk code will not know about that, so then a new netns will be created due to
1.
above and then runc itself will be started inside that new netns due to2.
above. - But then runc is going to start the actual Firecracker process inside the separate netns specified as part of CreateVM, which is not where CNI interfaces were actually created, so the VM won't see any of them.
There are probably multiple ways to address this, not sure yet which one is best:
- Is it possible to have firecracker-containerd actually set the netns field in the go sdk's
machine.JailerConfig
when it was set in theCreateVM
's JailerConfig? - If the above isn't possible, could we change the Go SDK to move the existing
machine.JailerConfig.NetNS
field to just be directly in themachine
object? Then we can conditionally set that field infirecracker-containerd
w/out creating a wholemachine.JailerConfig
object.
Let me know what you think.
a7af606
to
56ed692
Compare
I think what I can do is modify the SDK code to create a netns handler by passing in the netns path. This will use a default netns in the default handlers, then during jailing it'll create and swap handlers with its netns. Then in the firecracker-containerd code I just need to inject the correct handlers. |
Waiting on firecracker-microvm/firecracker-go-sdk#155 to be merged |
554d64c
to
b7b87f3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also update one of the tests in cni_integ_test.go
to use a runc jailer config? Just to make sure it interacts with the network namespacing as expected
bebea92
to
6e4ccce
Compare
0e6cbbf
to
b825062
Compare
go.sum
Outdated
github.com/firecracker-microvm/firecracker-go-sdk v0.17.1-0.20191029213755-dbf9a1e05f09 h1:JDfRpK+V2J1Es+Xm6aMJjCqvA4xv1kuWnJfeSopyDwo= | ||
github.com/firecracker-microvm/firecracker-go-sdk v0.17.1-0.20191029213755-dbf9a1e05f09/go.mod h1:tVXziw7GjioCKVjI5/agymYxUaqJM6q7cp9e6kwjo8Q= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
go mod tidy
may remove the lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Fixed
b825062
to
0337126
Compare
runtime/runc_jailer.go
Outdated
} | ||
func (j *runcJailer) overwriteConfig(cfg *Config, machineConfig *firecracker.Config, socketPath, configPath string) error { | ||
var err error | ||
j.once.Do(func() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of the once here? The all operations inside the closure look have no side-effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
caches the config so multiple reads on the file do not occur.
Added some docs to clarify the intention
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the function is only called by BuildJailedMachine() -> BuildJailedRootHandler() (this one cloud be private) -> overwriteConfig(). The cache won't be invalidated, even confgPath is different.
Can we remove this one for now? I don't think this file read would be a hot spot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was worried about the file system call, but if you think it isn't going to be a hot spot I can remove it.
2fe34e8
to
3381183
Compare
3381183
to
9a9c431
Compare
8d3c678
to
e18daaa
Compare
runtime/runc_jailer.go
Outdated
func (j *runcJailer) overwriteConfig(cfg *Config, machineConfig *firecracker.Config, socketPath, configPath string) error { | ||
var err error | ||
// here we attempt to cache the runc config. If the config has already been | ||
// cached, we will return immediately |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this comment still relevant? Otherwise LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, fixed!
e18daaa
to
23204f6
Compare
|
||
if err = json.Unmarshal(configBytes, &spec); err != nil { | ||
return nil, errors.Wrapf(err, "failed to unmarshal firecracker-runc-config.json") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use runcConfigPath instead of hard-coding firecracker-runc-config.json here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to use Sprintf inside Wrapf :)
23204f6
to
8903ba8
Compare
|
||
if err = json.Unmarshal(configBytes, &spec); err != nil { | ||
return nil, errors.Wrapf(err, "failed to unmarshal firecracker-runc-config.json") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to use Sprintf inside Wrapf :)
8903ba8
to
cc43916
Compare
lol, fixed! |
cc43916
to
5dc0b68
Compare
5dc0b68
to
0100a64
Compare
This change allows for users to pass in a custom network namespace in the create vm request. This will then pass that netns to the SDK which will run the VM in that netns. Signed-off-by: xibz <impactbchang@gmail.com>
0100a64
to
e1c305d
Compare
This adds netns specification per create vm request. In the event that
no netns was found in the runc config, we will then make sure of what
was passed into the create vm request
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.