[shimV2] adds core pod, container and process controllers#2674
[shimV2] adds core pod, container and process controllers#2674rawahars wants to merge 1 commit intomicrosoft:mainfrom
Conversation
Adds the `internal/controller` package hierarchy with three new sub-packages that provide lifecycle management for Linux Containers on Windows (LCOW): - `linuxcontainer`: manages the full lifecycle of a single LCOW container inside a Utility VM, including host-side resource allocation (SCSI layers, Plan9 shares, vPCI devices), guest-side container creation via the GCS, and state machine transitions. - `pod`: manages a single pod running inside a UVM, owning the network controller and tracking all container controllers belonging to the pod. - `process`: manages individual process (exec) instances within a container, handling IO plumbing, signal delivery, exit status reporting, and a linear state machine. Each package includes comprehensive unit tests, mock types, and documentation. Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
| c.mu.Lock() | ||
| defer c.mu.Unlock() | ||
|
|
||
| switch c.state { |
| if signalOptions != nil { | ||
| isDelivered, err = c.process.Signal(ctx, signalOptions) | ||
| } else { | ||
| // Legacy path: signals are not supported, issue a direct terminate. |
There was a problem hiding this comment.
Why do we have a legacy path here? Legacy for who?
| // examples: | ||
| // - sandbox:///a/dirInUvm destination:/b/dirInContainer | ||
| // - sandbox-tmp:///a/dirInUvm destination:/b/dirInContainer | ||
| // - uvm:///a/dirInUvm destination:/b/dirInContainer |
There was a problem hiding this comment.
How are any of these different lol? The prefix examples all look the same
| } | ||
|
|
||
| // Map the share into the guest. | ||
| guestPath, err := c.plan9.MapToGuest(ctx, reservationID) |
There was a problem hiding this comment.
Dont you need to immediately store the reservation? So if the Map is an error you can safely always unmap because you have the reservation?
| isBlockDev := strings.HasPrefix(mount.Destination, guestpath.BlockDevMountPrefix) | ||
|
|
||
| // Reserve the mount. | ||
| reservationID, err := c.scsi.Reserve(ctx, diskConfig, scsiMount.Config{ |
| if spec.Root == nil { | ||
| spec.Root = &specs.Root{} | ||
| } | ||
| spec.Root.Path = c.layers.rootfsPath |
There was a problem hiding this comment.
Hmm. It seems like we should not apply changes to the original and do this after we have a deep copy right?
| pciID, virtualFunctionIndex := vpci.GetDeviceInfoFromPath(device.ID) | ||
|
|
||
| // Reserve the device on the host. | ||
| vmBusGUID, err := c.vpci.Reserve(ctx, vpci.Device{ |
| } | ||
|
|
||
| // Parse the runtime options from the request. | ||
| shimOpts, err := vmutils.UnmarshalRuntimeOptions(ctx, opts.Options) |
There was a problem hiding this comment.
Should this stay in the service layer? I'm wondering if this create call should just take in the OCI spec and deserialized options?
| ScratchPath: c.layers.scratch.guestPath, | ||
| }); err != nil { | ||
| log.G(ctx).WithError(err).Error("failed to remove combined layers from guest") | ||
| } |
There was a problem hiding this comment.
If you want this retryable you need to unwind the state. so like c.layers.layersCombined is now false if this succeeds so you dont go into here etc.
| } | ||
|
|
||
| // Unmap additional SCSI mounts. | ||
| for _, id := range c.scsiResources { |
There was a problem hiding this comment.
Same here, if you get a success you would remove that one so its continuable
2 participants
Adds the
internal/controllerpackage hierarchy with three new sub-packages that provide lifecycle management for Linux Containers on Windows (LCOW):linuxcontainer: manages the full lifecycle of a single LCOW container inside a Utility VM, including host-side resource allocation (SCSI layers, Plan9 shares, vPCI devices), guest-side container creation via the GCS, and state machine transitions.pod: manages a single pod running inside a UVM, owning the network controller and tracking all container controllers belonging to the pod.process: manages individual process (exec) instances within a container, handling IO plumbing, signal delivery, exit status reporting, and a linear state machine.Each package includes comprehensive unit tests, mock types, and documentation.