Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type NotReadyError ¶ added in v0.14.0
NotReadyError says the container is attachable but has not booted yet, which is worth waiting for. It is distinct from "not attachable" so a client can tell a race from a permanent answer instead of retrying both for two minutes and then reporting one generic failure.
func (NotReadyError) Error ¶ added in v0.14.0
func (e NotReadyError) Error() string
type Server ¶
type Server struct {
Log *slog.Logger
CC *containerd.Client
EAC *entityserver_v1alpha.EntityAccessClient
Namespace string
// Hubs lets Attach join a client to a container's existing primary process
// rather than executing a second one beside it. The sandbox controller on
// this node populates it.
Hubs *sandbox.HubRegistry
}
func NewServer ¶ added in v0.3.0
func NewServer(log *slog.Logger, cc *containerd.Client, eac *entityserver_v1alpha.EntityAccessClient, namespace string, hubs *sandbox.HubRegistry) *Server
NewServer creates a new exec Server.
func (*Server) Attach ¶ added in v0.14.0
func (s *Server) Attach(ctx context.Context, req *exec_v1alpha.SandboxExecAttach) error
Attach joins the caller to a container's existing primary process.
This is deliberately not Exec. Exec starts a second process inside the container, which means the thing you are "attached" to belongs to your connection: it dies when you disconnect, and its exit code goes with it. That is fine for `miren sandbox exec`, where running a command is the point, and wrong for a task run, where the command is the workload and your terminal is just a window onto it.
So Attach subscribes to the container's stdio instead. Several clients can watch at once, any of them can leave, and none of it reaches the workload -- which is what lets a run outlive the client that started it.
func (*Server) Exec ¶
func (s *Server) Exec(ctx context.Context, req *exec_v1alpha.SandboxExecExec) error
Source Files