-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Sandbox API #6703
Sandbox API #6703
Conversation
|
||
func init() { | ||
plugin.Register(&plugin.Registration{ | ||
Type: plugin.ServicePlugin, |
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.
I think this is cleanup we need to or should do across the service packages today, but in the case where there is a defined interface for service, it is better to export an implementation of that interface rather than that of the generated API client.
var _ sb.Store = (*remoteSandboxStore)(nil) | ||
|
||
// NewRemoteSandboxStore create client for sandbox store | ||
func NewRemoteSandboxStore(client api.StoreClient) sb.Store { |
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.
Note for followup: This can be moved to a subpackage such as sandbox/proxy
@@ -155,3 +159,17 @@ func WithIntrospectionService(in introspection.Service) ServicesOpt { | |||
s.introspectionService = in | |||
} | |||
} | |||
|
|||
// WithSandboxStore sets the sandbox store. | |||
func WithSandboxStore(client sandboxsapi.StoreClient) ServicesOpt { |
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.
Note for follow up: We are trying to prevent directly using these generated interfaces in the client interface. The alternative would be to explicitly get an instance of the interface using the API client and passing in that instance.
Mostly just a few questions for me. I think we can handle some of the changes in follow-ups since they are similar to ongoing refactoring around the API and protobufs. If we can agree on the API we should just get this in. |
Build succeeded.
|
/test pull-containerd-node-e2e |
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 there some way to test this with ctr?
I see I can create a sandbox but then what?
I see there is a running v2 shim after.
Apologies, I'm a bit confused as to what's supposed to happen for these sandboxes.
When I create a sandbox using defaults I get a runc-v2 shim with no tasks.
How do I attach a task to it?
How would cri use this to implement the pod sandbox?
sandbox/controller.go
Outdated
// When running the traditional containerd shim, the workflow looks as follows: | ||
// For each new task we're about to run: | ||
// 1. Invoke `shim_binary --start` to obtain `TaskService` address (printed in stdout) | ||
// 2. Call TaskService.RunContainer(id=1) |
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.
I don't think these RunContainer calls are a real API? Is the doc out of date with the implementation?
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.
Yep, removed outdated docs
Name: "run", | ||
Aliases: []string{"create", "c", "r"}, | ||
Usage: "run a new sandbox", | ||
ArgsUsage: "[flags] <pod-config.json> <sandbox-id>", |
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.
No pod-config.json, I think?
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.
This can be any spec recognized to a shim implementation.
These includes the container spec used when launching pause container:
containerd/pkg/cri/server/sandbox_run.go
Line 177 in 887615c
spec, err := c.sandboxContainerSpec(id, config, &image.ImageSpec.Config, sandbox.NetNSPath, ociRuntime.PodAnnotations) |
} | ||
|
||
for _, sandbox := range list { | ||
_, err := fmt.Fprintf(writer, "%s\t%s\t%s\t\n", sandbox.ID, sandbox.CreatedAt, sandbox.Runtime.Name) |
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.
for follow up maybe, but this output is not easy to read.
ID CREATED RUNTIME
test 2022-03-30 21:39:50.043075106 +0000 UTC io.containerd.runc.v2
|
||
message ControllerStartRequest { | ||
string sandbox_id = 1; | ||
repeated containerd.types.Mount rootfs = 2; |
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.
Where does this rootfs come from? Who determines what the rootfs is?
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.
Client is expected to specify this.
Same way as CRI does today via WithNewSnapshot
call when creating a sandbox.
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.
For VMs (incl. Firecracker), would we assume they boot Linux from the rootfs? How much compatibility between non-VM sandboxes and VM sandboxes is expected?
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.
I've been working on a prototype with "pause" containers and this field was needed to pass a mount, so the shim could launch pause containers from the runtime via start sandbox request. For Firecracker this can be an image to boot from. Here containerd's client is required to provide proper values that will be recognized by shim implementations.
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.
I've been working on a prototype with "pause" containers and this field was needed to pass a mount, so the shim could launch pause containers from the runtime via start sandbox request. For Firecracker this can be an image to boot from. Here containerd's client is required to provide proper values that will be recognized by shim implementations.
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.
Where does this rootfs come from? Who determines what the rootfs is?
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.
Client is expected to specify this.
Same way as CRI does today viaWithNewSnapshot
call when creating a sandbox.
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.
I've been working on a prototype with "pause" containers and this field was needed to pass a mount, so the shim could launch pause containers from the runtime via start sandbox request. For Firecracker this can be an image to boot from. Here containerd's client is required to provide proper values that will be recognized by shim implementations.
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.
I've been working on a prototype with "pause" containers and this field was needed to pass a mount, so the shim could launch pause containers from the runtime via start sandbox request. For Firecracker this can be an image to boot from. Here containerd's client is required to provide proper values that will be recognized by shim implementations.
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.
Client is expected to specify this.
Same way as CRI does today viaWithNewSnapshot
call when creating a sandbox.
This is daemon side API to manage sandboxes.
Yes, there is
This requires changes on CRI side. That's ongoing work. |
Build succeeded.
|
|
||
import "google/protobuf/any.proto"; | ||
import "google/protobuf/timestamp.proto"; | ||
import weak "gogoproto/gogo.proto"; |
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.
We should remove weak
after merge.
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.
We should remove
weak
after merge.
|
||
message ControllerStartRequest { | ||
string sandbox_id = 1; | ||
repeated containerd.types.Mount rootfs = 2; |
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.
For VMs (incl. Firecracker), would we assume they boot Linux from the rootfs? How much compatibility between non-VM sandboxes and VM sandboxes is expected?
|
||
message ControllerShutdownRequest { | ||
string sandbox_id = 1; | ||
uint32 timeout_secs = 2; |
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.
- Would we need the timeout on ControllerStartRequest?
- Should we have this timeout in addition to the underlying RPC framework's timeout? For example, gRPC itself could have its own timeout. https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
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.
Sandbox implementations are expected to shutdown both running containers (if any) and the sandbox itself on shutdown request. So timeout would be useful to try to shutdown containers properly first and in case if that take too long - kill them. There is similar logic in CRI:
containerd/pkg/cri/server/sandbox_stop.go
Line 51 in 1ba613e
func (c *criService) stopPodSandbox(ctx context.Context, sandbox sandboxstore.Sandbox) error { |
Start request should just launch a new sandbox, so there is no need to have a dedicated timeout parameter.
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.
This seems a little high-level to me. Shouldn't the client drive this?
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Build succeeded.
|
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.
LGTM
PR containerd#6366 implemented a tree-wide change to replace github.com/pkg/errors to errors. The new sandbox API PR containerd#6703 had few errors.Wrap*() leftovers and pulled github.com/pkg/errors back. This commit replaces those leftovers by following the pattern in containerd#6366. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
PR containerd#6366 implemented a tree-wide change to replace github.com/pkg/errors to errors. The new sandbox API PR containerd#6703 had few errors.Wrap*() leftovers and pulled github.com/pkg/errors back. This commit replaces those leftovers by following the pattern in containerd#6366. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Last rebase didn't go well and Github won't let me to reopen the old PR (nor recognizes new commits). Context and discussion here: #5396