Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
112 changes: 98 additions & 14 deletions specs-go/config.go
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,8 @@ type Spec struct {
Linux Linux `json:"linux" platform:"linux,omitempty"`
// Solaris is platform specific configuration for Solaris containers.
Solaris Solaris `json:"solaris" platform:"solaris,omitempty"`
// Windows is the platform specific configuration for Windows based containers.
Windows *Windows `json:"windows,omitempty" platform:"windows"`
}

// Process contains information to start a specific application inside the container.
Expand All @@ -51,17 +53,21 @@ type Process struct {
ApparmorProfile string `json:"apparmorProfile,omitempty" platform:"linux"`
// SelinuxLabel specifies the selinux context that the container process is run as. (this field is platform dependent)
SelinuxLabel string `json:"selinuxLabel,omitempty" platform:"linux"`

// InitialConsoleSize specifies the initial [h,w] of the console. (this field is platform dependent)
InitialConsoleSize [2]int `json:"initialConsoleSize,omitempty" platform:"windows"`
}

// User specifies Linux/Solaris specific user and group information for the container's
// main process.
// User specifies the user information for the container
type User struct {
// UID is the user id. (this field is platform dependent)
UID uint32 `json:"uid" platform:"linux,solaris"`
// GID is the group id. (this field is platform dependent)
GID uint32 `json:"gid" platform:"linux,solaris"`
// AdditionalGids are additional group ids set for the container's process. (this field is platform dependent)
AdditionalGids []uint32 `json:"additionalGids,omitempty" platform:"linux,solaris"`
// User is the user name. (this field is platform dependent)
User string `json:"user" platform:"windows"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason why it's not username, and can we expect a groupname in the future ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a proof-of-concept PR. In the actual PR (now in master), it's username. https://github.com/opencontainers/runtime-spec/blob/master/specs-go/config.go#L65. There are no plans for groups in the future (it's not really something that makes sense on Windows).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, was just curious. Thanks.

}

// Root contains information about the container's root filesystem on the host.
Expand All @@ -79,6 +85,8 @@ type Platform struct {
OS string `json:"os"`
// Arch is the architecture
Arch string `json:"arch"`
// OSVersion is the version of the operating system. (this field is platform dependent)
OSVersion string `json:"os.version,omitempty" platform:"windows"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you expect this field to be used? The consensus for config settings that aren't supported by all versions of the Linux kernel (all the config settings?) seems to be:

Just return kernel errors in a reasonable way. You don't have to check for this sort of thing ahead of time.

See here and #418.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use it today in docker/docker for difference in functionality between versions of Windows as opposed to whether things are supported or not supported. Hence it's not a case of us being able to return an error in the way described above.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Jun 22, 2016 at 09:25:09AM -0700, John Howard wrote:

  • // OSVersion is the version of the operating system. (this field is platform dependent)
  • OSVersion string json:"os.version,omitempty" platform:"windows"

We use it today in docker/docker for difference in functionality
between versions of Windows as opposed to whether things are
supported or not supported.

Grepping turned up [1,2]. I still think that is a runtime-flag
concern (especially if process.terminal is a runtime-flag concern
3). Can't the code that currently sets OSVersion just switch over
to setting a runtime flag? It doesn't seem like that would be a big
change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why can't we use the existing OS field?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Jun 22, 2016 at 07:55:51PM -0700, Mrunal Patel wrote:

  • // OSVersion is the version of the operating system. (this field is platform dependent)
  • OSVersion string json:"os.version,omitempty" platform:"windows"

Curious why can't we use the existing OS field?

Would you use ‘old-windows’ or some such for “Windows before build
14350” 1? I think it's better to keep ‘windows’ there and pass that
build information through as a separate thing. I just think the
separate thing should be a runtime flag instead of a config option.

}

// Mount specifies a mount for a container.
Expand All @@ -90,8 +98,10 @@ type Mount struct {
// Source specifies the source path of the mount. In the case of bind mounts on
// Linux based systems this would be the file on the host.
Source string `json:"source"`
// Options are fstab style mount options.
Options []string `json:"options,omitempty"`
// Options are fstab style mount options. (this field is platform dependent)
Options []string `json:"options,omitempty" platform:"linux,solaris"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it should be part of #439.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure - that PR is documentation. The Options are very different between *nix and Windows - Windows obviously has no concept of fstab. I added the platform tag to make this field not applicable to Windows, and added a separate field which is for Windows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Jun 22, 2016 at 09:29:38AM -0700, John Howard wrote:

  • // Options are fstab style mount options.
  • Options []string json:"options,omitempty"
  • // Options are fstab style mount options. (this field is platform dependent)
  • Options []string json:"options,omitempty" platform:"linux,solaris"

I'm not sure - that PR is documentation.

The pattern so far in this repo has been to try and land the
(canonical, #342) Markdown docs in the same PR that updates the Go
types. I think the change you're making to Mount.Options here makes
sense, and think that #439 has the associated Markdown updates. Why
not make both of those changes in one atomic pivot PR?

// Readonly specifies if the mount should be read-only. (this field is platform dependent)
Readonly bool `json:"readonly" platform:"windows"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you parse a constant readonly from existing options to set this boolean for Windows?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Wed, Jun 22, 2016 at 07:57:58PM -0700, Mrunal Patel wrote:

  • // Options are fstab style mount options.
  • Options []string json:"options,omitempty"
  • // Options are fstab style mount options. (this field is platform dependent)
  • Options []string json:"options,omitempty" platform:"linux,solaris"
  • // Readonly specifies if the mount should be read-only. (this field is platform dependent)
  • Readonly bool json:"readonly" platform:"windows"

Could you parse a constant readonly from existing options to set
this boolean for Windows?

Or stay compatible with Linux by using ‘ro’ and ‘rw’ 1. Matching
Linux isn't a big deal, but I'm surprised there's no Windows analog to
1. Is “readonly” really the only knob?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. In the process of updating the docker engine to do exactly that at moby/moby#26577.

}

// Hook specifies a command that is run at a particular event in the lifecycle of a container
Expand Down Expand Up @@ -123,7 +133,7 @@ type Linux struct {
Sysctl map[string]string `json:"sysctl,omitempty"`
// Resources contain cgroup information for handling resource constraints
// for the container
Resources *Resources `json:"resources,omitempty"`
Resources *LinuxResources `json:"resources,omitempty"`
// CgroupsPath specifies the path to cgroups that are created and/or joined by the container.
// The path is expected to be relative to the cgroups mountpoint.
// If resources are specified, the cgroups at CgroupsPath will be updated based on resources.
Expand Down Expand Up @@ -252,7 +262,7 @@ type BlockIO struct {
}

// Memory for Linux cgroup 'memory' resource management
type Memory struct {
type LinuxMemory struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing this sort of rename on a per-collision basis (e.g. “we now have a Windows memory structure, so rename MemoryLinuxMemory”) seems like it will cause stability headaches for downstream consumers of this package. I suggest aggressively namespacing now (and when new types are added), because “yeah, Solaris can also use LinuxInterfacePriority” is much easier on downstream users than “We're renaming InterfacePriority to LinuxInterfacePriority in runtime-spec v1.2”.

// Memory limit (in bytes).
Limit *uint64 `json:"limit,omitempty"`
// Memory reservation or soft_limit (in bytes).
Expand All @@ -268,7 +278,7 @@ type Memory struct {
}

// CPU for Linux cgroup 'cpu' resource management
type CPU struct {
type LinuxCPU struct {
// CPU shares (relative weight (ratio) vs. other cgroups with cpu shares).
Shares *uint64 `json:"shares,omitempty"`
// CPU hardcap limit (in usecs). Allowed cpu time in a given period.
Expand All @@ -291,34 +301,34 @@ type Pids struct {
Limit *int64 `json:"limit,omitempty"`
}

// Network identification and priority configuration
type Network struct {
// LinuxNetwork identification and priority configuration
type LinuxNetwork struct {
// Set class identifier for container's network packets
ClassID *uint32 `json:"classID"`
// Set priority of network traffic for container
Priorities []InterfacePriority `json:"priorities,omitempty"`
}

// Resources has container runtime resource constraints
type Resources struct {
// LinuxResources has container runtime resource constraints for Linux based containers
type LinuxResources struct {
// Devices are a list of device rules for the whitelist controller
Devices []DeviceCgroup `json:"devices"`
// DisableOOMKiller disables the OOM killer for out of memory conditions
DisableOOMKiller *bool `json:"disableOOMKiller,omitempty"`
// Specify an oom_score_adj for the container.
OOMScoreAdj *int `json:"oomScoreAdj,omitempty"`
// Memory restriction configuration
Memory *Memory `json:"memory,omitempty"`
Memory *LinuxMemory `json:"memory,omitempty"`
// CPU resource restriction configuration
CPU *CPU `json:"cpu,omitempty"`
CPU *LinuxCPU `json:"cpu,omitempty"`
// Task resource restriction configuration.
Pids *Pids `json:"pids,omitempty"`
// BlockIO restriction configuration
BlockIO *BlockIO `json:"blockIO,omitempty"`
// Hugetlb limit (in bytes)
HugepageLimits []HugepageLimit `json:"hugepageLimits,omitempty"`
// Network restriction configuration
Network *Network `json:"network,omitempty"`
Network *LinuxNetwork `json:"network,omitempty"`
}

// Device represents the mknod information for a Linux special device file
Expand Down Expand Up @@ -469,3 +479,77 @@ type Syscall struct {
Action Action `json:"action"`
Args []Arg `json:"args,omitempty"`
}

// Windows contains platform specific configuration for Windows based containers.
type Windows struct {
// Resources contains constraints for containers.
Resources *WindowsResources `json:"resources,omitempty"`
// Networking contains the network connection settings for containers.
Networking *Networking `json:"networking,omitempty"`
// FirstStart is an optimization on first boot of a container.
FirstStart bool `json:"first_start,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This property is likely best delegated to a runtime flag. See previous discussion on flags vs. config settings here and here, but the threshold seems to be close to “can you tell that was set from inside the container?”.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. PR submitted to docker moby/moby#26650

// LayerFolder is the path to the current layer folder.
LayerFolder string `json:"layer_folder,omitempty"`
// Layer contains the filepaths of the parent layers.
LayerPaths []string `json:"layer_paths,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two layer settings seem like they belong to image-spec or similar. Are they really a runtime concern? Perhaps this will become clearer once this PR grows Markdown docs.

// Settings relating to Hyper-V containers, omitted otherwise.
HvRuntime *HvRuntime `json:"hv_runtime,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably best delegated to containerd or some higher layer. See previous discussion about the very-similar HypervisorPath (since dropped from #405) here and here.

}

// WindowsResources has container runtime resource constraints for Windows based containers.
type WindowsResources struct {
// Network resource configuration.
Network *WindowsNetwork `json:"network,omitempty"`
// Memory resource configuration.
Memory *WindowsMemory `json:"memory,omitempty"`
// CPU resource configuration.
CPU *WindowsCPU `json:"cpu,omitempty"`
// Storage resource configuration.
Storage *WindowsStorage `json:"storage,omitempty"`
}

// WindowsNetwork has network runtime resource constraings for Windows based containers.
type WindowsNetwork struct {
// Bandwidth is the maximum egress bandwidth in bytes per second.
Bandwidth *uint64 `json:"bandwidth,omitempty"`
}

// WindowsMemory has memory runtime resource constraints for Windows based containers.
type WindowsMemory struct {
// Memory limit (in bytes).
Limit *int64 `json:"limit,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentionally signed? If so, please explain what negative values mean when you land the Markdown docs ;).

// Memory reservation (in bytes).
Reservation *uint64 `json:"reservation,omitempty"`
}

// WindowsCPU has CPU runtime resource constraints for Windows based containers.
type WindowsCPU struct {
// Number of CPUs available to the container. This is an approximation for Windows Server Containers.
Count *uint64 `json:"count,omitempty"`
// CPU shares (relative weight (ratio) vs. other containers with cpu shares). Range is from 1 to 10000.
Shares *uint64 `json:"shares,omitempty"`
// Percent of available CPUs usable by the container.
Percent *int64 `json:"percent,omitempty"`
}

// WindowsStorage has storage resource constraints for Windows based containers.
type WindowsStorage struct {
// Specifies maximum Iops for the system drive.
Iops *uint64 `json:"iops,omitempty"`
// Specifies maximum bytes per second for the system drive.
Bps *uint64 `json:"bps,omitempty"`
// Sandbox size indicates the size to expand the system drive to if it is currently smaller.
SandboxSize *uint64 `json:"sandbox_size,omitempty"`
}

// Networking contains the network configuration for Windows based containers.
type Networking struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be renamed once we determine if this is necessary.

// List of endpoints to be attached to the container.
EndpointList []string `json:"endpoints,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect Endpoints instead of EndpointList for the Go parameter behind and endpoints JSON parameter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this expected to be used for? Can you provide an example?

}

// HvRuntime contains the configuration for Windows based Hyper-V containers.
type HvRuntime struct {
// ImagePath is the path to the Utility VM image.
ImagePath string `json:"image_path,omitempty"`
}