CRI-API - Add rootfs size to WindowsContainerResources

[marosset]

Signed-off-by: Mark Rossetti marosset@microsoft.com

What type of PR is this?

/kind feature

What this PR does / why we need it:

This PR adds a new field to WindowsContainerResources CRI-API objects that is used to specify the size of the rootfs/scratch space used for Windows containers.

This value defaults to 20Gb on Windows.
This value can also either be specified per container when starting containers with Docker cli with --storage-opt and can also be set globally by specifying storage-opts in the docker config.

Currently we cannot change this value from the 20Gb default in Kubernetes clusters using containerd as the container runtime.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

This PR only adds the new field to the CRI-API field.

We are doing this so that after 1.24 releases containerd can add support for the new field and hopefully have full support in the 1.7 release.

SIG-Windows will create a KEP in the 1.25 release to cover the Kubernetes related changes to expose this new value in the pod spec.

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

More information on how the rootfs / scratch space for Windows containers can be found at https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-storage

/sig windows
/sig node
/milestone v1.24

[marosset]

/assign @dcantah

[marosset]

/retest

[dcantah]

cc @kevpar. Does this seem sound to you? This seems like a much needed addition to me

[marosset]

/triage accepted
/priority important-soon

[jterry75]

Only question I have is if this will be per container as the change in the proto is or if its per sandbox. Do we need both?

[marosset]

Only question I have is if this will be per container as the change in the proto is or if its per sandbox. Do we need both?

I'd like it to be per-container.
We'll need to do some design work in 1.25 to see how/where to expose this in the pod-specs tho...

[dcantah]

I'd prefer to have this be per container if possible.. I think that's the main advantage for this if its on the spec itself

[marosset]

/retest

[matthyx]

/uncc

[dcantah]

/lgtm

[dcantah]

Curious why the other _bytes fields are int64's, but that seems to be the convention

[marosset]

Curious why the other _bytes fields are int64's, but that seems to be the convention

I had the same question...

[marosset]

/test pull-kubernetes-integration

[marosset]

/test pull-kubernetes-integration

[marosset]

/test pull-kubernetes-integration

[dcantah]

/lgtm

[marosset]

/assign @sjenning @murnalp
For node review / approval

[k8s-ci-robot]

@marosset: GitHub didn't allow me to assign the following users: murnalp.

Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @sjenning @murnalp
For node review / approval

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[marosset]

/assign @mrunalp

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: marosset, mrunalp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/cri-api/pkg/OWNERS [mrunalp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment