profile
viewpoint
Renaud Gaubert RenaudWasTaken Nvidia Santa Clara Working on GPU integration in containers and orchestration engines

NVIDIA/k8s-device-plugin 799

NVIDIA device plugin for Kubernetes

NVIDIA/libnvidia-container 246

NVIDIA container runtime library

NVIDIA/gpu-operator 178

NVIDIA GPU Operator creates/configures/manages GPUs atop Kubernetes

NVIDIA/gpu-feature-discovery 51

GPU plugin to the node feature discovery for Kubernetes

NVIDIA/nvidia-container-toolkit 14

Build and run containers leveraging NVIDIA GPUs

RenaudWasTaken/cdi 10

Container Device Interface - Devices for Linux containers

NVIDIA/container-config 4

Set up your container runtime with NVIDIA GPUs support

NVIDIA/container-wiki 1

Documentation for the NVIDIA cloud native technologies

RenaudWasTaken/community 1

Kubernetes community content

Dubrzr/thjx2017 0

Théorie des jeux - SERVEUR

push eventNVIDIA/gpu-feature-discovery

Kevin Klues

commit sha 73004750254b6b21c379b4da96797c279f7a5246

Update nfd.yaml to v0.6.0 following example on official project page Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Renaud Gaubert

commit sha 766519ebc417f8b3ab724b92c508763fb91c4391

Merge branch 'upstream-update-nfd' into 'master' Update nfd.yaml to v0.6.0 following example on official project page See merge request nvidia/kubernetes/gpu-feature-discovery!19

view details

push time in 3 days

push eventNVIDIA/gpu-feature-discovery

Kevin Klues

commit sha 4acc96e75ca2c8aea2b0829222f198ad4f8b31ec

Update README to point to correct image name when building from source Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Renaud Gaubert

commit sha 5820aea1407181286271aea87134c5147d93780f

Merge branch 'upstream-update-readme' into 'master' Update README to point to correct image name when building from source See merge request nvidia/kubernetes/gpu-feature-discovery!18

view details

push time in 3 days

pull request commentopencontainers/runc

Move integration tests to opensuse

It does seem like it's missing the mount command though....

RenaudWasTaken

comment created time in 4 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 745dd448d313c6eae51f0f5fffc351a7eb9ffa8e

Switch to opensuse Tumbleweed Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 4 days

pull request commentopencontainers/runc

Move integration tests to opensuse

So umount is not part of tumbleweed!

RenaudWasTaken

comment created time in 4 days

pull request commentopencontainers/runc

Move integration tests to opensuse

Switched to tumbleweed

RenaudWasTaken

comment created time in 4 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 1693452d89c65aae61856783d7588ffd948f0814

Switch to opensuse Tumbleweed Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 4 days

Pull request review commentopencontainers/runc

Move integration tests to opensuse

 RUN echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontain     && apt-get clean \     && rm -rf /var/cache/apt /var/lib/apt/lists/*; -# install umoci-RUN curl -o /usr/local/bin/umoci -fsSL https://github.com/opencontainers/umoci/releases/download/v0.4.5/umoci.amd64 \+# install umoci, retry with an exponential backoff strategy+RUN curl --connect-timeout 5 --max-time 10 --retry 5 --retry-delay 0 --retry-max-time 40 -o /usr/local/bin/umoci \+         -fsSL https://github.com/opencontainers/umoci/releases/download/v0.4.5/umoci.amd64 \

Addressed!

RenaudWasTaken

comment created time in 4 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 4079b6f3e8ddabb8e335b6b5bd16426cbcf92b24

Bump umoci version Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 4 days

pull request commentopencontainers/runc

Move integration tests to opensuse

Hmm there's only a latest tag available for tumbleweed, is that ok? https://hub.docker.com/r/opensuse/tumbleweed

RenaudWasTaken

comment created time in 4 days

pull request commentopencontainers/runc

Move integration tests to opensuse

I managed to get caching running yesterday :) ! I don't think there is any significant difference with the master CI now! This is ready for review! Let me know if I need to change anything :)

RenaudWasTaken

comment created time in 4 days

created tagNVIDIA/libnvidia-container

tagv1.2.0-rc.3

NVIDIA container runtime library

created time in 4 days

push eventNVIDIA/libnvidia-container

Kevin Klues

commit sha 3d36aad5ff63bfe1cde52e2d3bad5bd412157bf1

WSL2 Support - Remove unnecessary umount and free Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Kevin Klues

commit sha 1755b48d00126c82a16631301fddcec2c5394990

Update changelog with last minute WSL fix for 1.2.0-rc.3 Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Kevin Klues

commit sha 531f4d44655031c57de5989735a7846056d722ab

Merge branch 'upstream-bump-1.2.0-rc.3' into 'master' Last Minute patch to WSL2 for 1.2.0-rc.3 See merge request nvidia/container-toolkit/libnvidia-container!33

view details

push time in 4 days

push eventNVIDIA/libnvidia-container

Kevin Klues

commit sha 51adffdeb8a314d201b33e7ae335eb34b9bb7d4d

Bump version to 1.2.0-rc.3 Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Kevin Klues

commit sha 87876419c49def344d5661590e38c6c88e882e58

Update changelog for 1.2.0-rc.3 Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Kevin Klues

commit sha 16ae202797e4e47d7095855df6dab6a7281de1d3

Merge branch 'upstream-bump-1.2.0-rc.3' into 'master' Bump version to 1.2.0-rc.3 See merge request nvidia/container-toolkit/libnvidia-container!32

view details

push time in 5 days

push eventNVIDIA/libnvidia-container

Raphael Boissel

commit sha 38198a81cbaa93bbb0c685484cfc52fe0788bc35

WSL2 Support - Fix error path in dxcore Previously, this error path did not correctly check for the alloc return value. Now it does. Signed-off-by: Raphael Boissel <rboissel@nvidia.com>

view details

Raphael Boissel

commit sha 53739009d60fe666e3ede795c8aca057ba429347

WSL2 Support - Fix error path when mounting the driver Previously, the store would reset the count of files before freeing the associated resources. Signed-off-by: Raphael Boissel <rboissel@nvidia.com>

view details

Kevin Klues

commit sha deced35eae548c5eb6267a105ad0edbbf27cca46

Merge branch 'wsl-fixes' into 'master' WSL2 fixes - Fixes two minor issues that were raised during static analysis See merge request dl/container-dev/libnvidia-container!29

view details

push time in 5 days

Pull request review commentcontainer-orchestrated-devices/container-device-interface

Add initial spec

+# Container Device Interface Specification++- [Version](#version)+- [Overview](#overview)+- [General considerations](#general-considerations)+- [CDI JSON Specification](#well-known-error-codes)+- [CDI CLI Specification](#well-known-error-codes)++## Version++This is CDI **spec** version **0.1.0**.++#### Released versions++Released versions of the spec are available as Git tags.++| Tag  | Spec Permalink   | Change |+| -----| -----------------| -------|++## Overview++The _Container Device Interface_, or _CDI_ describes a mechanism for container runtimes to create containers which are able to interact with third party devices.++For third party devices, it is often the case that interacting with these devices require container runtimes to expose more than a device node. For example a third part device might require you to have kernel modules loaded, host libraries mounted or specific procfs path exposed/masked.++The _Container Device Interface_ describes a mechanism which allows third party vendors to perform these operations such that it doesn't require changing the container runtime.++The mechanism used is a JSON file (similar the [Container Network Interface (CNI)][cni]) which allows vendors to describe the operations the container runtime should perform on the container's [OCI specification][oci].++The Container Device Interface enables the following two flows:++A. Device Installation+   1. A user installs a third party device driver (and third party device) on a machine.+   2. The device driver installation software writes a JSON file at a well known path (`/etc/cdi/vendor.json`).++B. Container Runtime+   1. A user runs a container with the argument `--device` followed by a device name.+   2. The container runtime reads the JSON file.+   3. The container runtime validates that the device is described in the JSON file.+   4. The container runtime pulls the container image.+   5. The container runtime generates an OCI specification.+   6. The container runtime transforms the OCI specification according to the instructions in the JSON file+++[cni]: https://github.com/containernetworking/cni+[oci]: https://github.com/opencontainers/runtime-spec++## General considerations++- The device configuration is in JSON format and can easily be stored in a file.+- The device configuration includes mandatory fields such as "name" and "version".+- Fields in CDI structures are required unless specifically marked optional.++For the purposes of this proposal, we define two terms very specifically:+- _container_ can be considered synonymous with a [Linux _network namespace_][namespaces].+  What unit this corresponds to depends on a particular container runtime implementation. +- _device_ which will refer to an actual hardware device.++The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optonal" are used as specified in [RFC 2119][rfc-2119].++[rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt+[namespaces]: http://man7.org/linux/man-pages/man7/namespaces.7.html++## CDI JSON Specification++### JSON Definition++```+{+    "cdiVersion": "0.1.0",+    "kind": "<name>",+    "container-runtime": ["<container-runtime-name>"], (optional)++    "cdiDevices": [+        {+            "name": "<name>",+            "nameShort": ["<short-name>", "<short-name>"], (optional)++            // Same as the below containerSpec field.+            // This field should only be applied to the Container's OCI spec+            // if that specific device is requested.+            "containerSpec": { ... }+        }+    ],++    // This field should be applied to the Container's OCI spec if any of the+    // devices defined above are requested on the CLI+    "containerSpec": [+        {+            "devices": [ (optional)+                {+                    "hostPath": "<path>",+                    "containerPath": "<path>",++                    // Cgroups permissions of the device, candidates are one or more of+                    // * r - allows container to read from the specified device.+                    // * w - allows container to write to the specified device.+                    // * m - allows container to create device files that do not yet exist.+                    "permissions": "<permissions>" (optional)+                }+            ]+            "mounts": [ (optional)+                {+                    "hostPath": "<source>",+                    "containerPath": "<destination>",+                    "options": "<OCI Mount Options>", (optional)+                }+            ],+            "hooks": [ (optional)+                {+                    "hookName": "<hookName>",+                    "path": "<path>",+                    "args": ["<arg>", "<arg>"], (optional)+                    "env":  [ "<envName>=<envValue>"], (optional)+                    "timeout": <int> (optional)+                }+            ]+        }+    ]+}+```++#### Specification version++* `cdiVersion` (string, REQUIRED) MUST be in [Semantic Version 2.0](https://semver.org) and specifies the version of the CDI specification used by the vendor.++#### Kind++* `kind` (string, REQUIRED) field specifies a label which uniquely identifies the device vendor.+  It can be used to disambiguate the vendor that matches a device, e.g: `docker/podman run --device vendor.com/device=foo ...`.+    * The `kind` and `kindShort` labels have two segments: a prefix and a name, separated by a slash (/).+    * The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (\_), dots (.), and alphanumerics between.+    * The prefix must be a DNS subdomain: a series of DNS labels separated by dots (.), not longer than 253 characters in total, followed by a slash (/).+    * Examples (not an exhaustive list):+      * Valid: `vendor.com/foo`, `foo.bar.baz/foo-bar123.B_az`.+      * Invalid: `foo`, `vendor.com/foo/`, `vendor.com/foo/bar`.++#### Container Runtime++* `containerRuntime` (array of string, OPTIONAL) indicates that this CDI specification targets only a specific container runtime.+  If this field is not indicated then container runtimes should consider that the JSON file targets all runtimes.+  If this field is indicated then container runtimes should only run it if one of the identifiers matches the container runtime's identifier.+  Possible values (not an exhaustive list): docker, podman, gvisor, lxc++#### CDI Devices++The `cdiDevices` field describes the set of hardware devices that can be requested by the container runtime user.+Note: For a CDI file to be valid, at least one entry must be specified in this array.++  * `cdiDevices` (array of objects, REQUIRED) list of devices provided by the vendor.+    * `name` (string, REQUIRED), name of the device, can be used to refer to it when requesting a device.+      * Beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (\_), dots (.), and alphanumerics between.+      * e.g: `docker/podman run --device foo ...`+    * `nameShort` (array of strings, OPTIONAL), alternative names for the device. Can be used to reduce the CLI verbosity+      * Entries in the array MUST use the same schema as the entry for the `name` field+    * `containerSpec` (object, OPTIONAL) this field is described in the next section.+      * This field should only be merged in the OCI spec if the device has been requested by the container runtime user.+++#### Container Spec++The `containerSpec` field describes edits to be made to the OCI specification. Currently only three kinds of edits can be made to the OCI specification: `devices`, `mounts` and `hooks`.++The `containerSpec` field is referenced in two places in the specification:+  * At the device level, where the edits MUST only be made if the matching device is requested by the container runtime user.+  * At the container level, where the edits MUST be made if any of the of the device defined in the `devices` field are requested.+++The `containerSpec` field has the following definition:+  * `devices` (array of objects, OPTIONAL) describes the device nodes that should be mounted:+    * `hostPath` (string, REQUIRED) path of the device on the host.+    * `containerPath` (string, REQUIRED) path of the device within the container.+    * `permissions` (string, OPTIONAL) Cgroups permissions of the device, candidates are one or more of:+      * r - allows container to read from the specified device.+      * w - allows container to write to the specified device.+      * m - allows container to create device files that do not yet exist.+  * `mounts` (array of objects, OPTIONAL) describes the mounts that should be mounted:+    * `hostPath` (string, REQUIRED) path of the device on the host.+    * `containerPath` (string, REQUIRED) path of the device within the container.+    * `permissions` (string, OPTIONAL) Cgroups permissions of the device, candidates are one or more of:+  * `hooks` (array of objects, OPTIONAL) describes the hooks that should be ran:+    * `hookName` is the name of the hook to invoke, if the runtime is OCI compliant it should be one of {createRuntime, createContainer, startContainer, poststart, poststop}.+      Runtimes are free to allow custom hooks but it is advised for vendors to create a specific JSON file targeting that runtime+    * `path` (string, REQUIRED) with similar semantics to IEEE Std 1003.1-2008 execv's path. This specification extends the IEEE standard in that path MUST be absolute.+    * `args` (array of strings, OPTIONAL) with the same semantics as IEEE Std 1003.1-2008 execv's argv.+    * `env` (array of strings, OPTIONAL) with the same semantics as IEEE Std 1003.1-2008's environ.+    * `timeout` (int, OPTIONAL) is the number of seconds before aborting the hook. If set, timeout MUST be greater than zero.

Do you mean that we should define what the timeout is if it's not set?

RenaudWasTaken

comment created time in 5 days

Pull request review commentcontainer-orchestrated-devices/container-device-interface

Add initial spec

+# Container Device Interface Specification++- [Version](#version)+- [Overview](#overview)+- [General considerations](#general-considerations)+- [CDI JSON Specification](#well-known-error-codes)+- [CDI CLI Specification](#well-known-error-codes)++## Version++This is CDI **spec** version **0.1.0**.++#### Released versions++Released versions of the spec are available as Git tags.++| Tag  | Spec Permalink   | Change |+| -----| -----------------| -------|++## Overview++The _Container Device Interface_, or _CDI_ describes a mechanism for container runtimes to create containers which are able to interact with third party devices.++For third party devices, it is often the case that interacting with these devices require container runtimes to expose more than a device node. For example a third part device might require you to have kernel modules loaded, host libraries mounted or specific procfs path exposed/masked.++The _Container Device Interface_ describes a mechanism which allows third party vendors to perform these operations such that it doesn't require changing the container runtime.++The mechanism used is a JSON file (similar the [Container Network Interface (CNI)][cni]) which allows vendors to describe the operations the container runtime should perform on the container's [OCI specification][oci].++The Container Device Interface enables the following two flows:++A. Device Installation+   1. A user installs a third party device driver (and third party device) on a machine.+   2. The device driver installation software writes a JSON file at a well known path (`/etc/cdi/vendor.json`).++B. Container Runtime+   1. A user runs a container with the argument `--device` followed by a device name.+   2. The container runtime reads the JSON file.+   3. The container runtime validates that the device is described in the JSON file.+   4. The container runtime pulls the container image.+   5. The container runtime generates an OCI specification.+   6. The container runtime transforms the OCI specification according to the instructions in the JSON file+++[cni]: https://github.com/containernetworking/cni+[oci]: https://github.com/opencontainers/runtime-spec++## General considerations++- The device configuration is in JSON format and can easily be stored in a file.+- The device configuration includes mandatory fields such as "name" and "version".+- Fields in CDI structures are required unless specifically marked optional.++For the purposes of this proposal, we define two terms very specifically:+- _container_ can be considered synonymous with a [Linux _network namespace_][namespaces].+  What unit this corresponds to depends on a particular container runtime implementation. +- _device_ which will refer to an actual hardware device.++The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optonal" are used as specified in [RFC 2119][rfc-2119].++[rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt+[namespaces]: http://man7.org/linux/man-pages/man7/namespaces.7.html++## CDI JSON Specification++### JSON Definition++```+{+    "cdiVersion": "0.1.0",+    "kind": "<name>",+    "container-runtime": ["<container-runtime-name>"], (optional)++    "cdiDevices": [+        {+            "name": "<name>",+            "nameShort": ["<short-name>", "<short-name>"], (optional)++            // Same as the below containerSpec field.+            // This field should only be applied to the Container's OCI spec+            // if that specific device is requested.+            "containerSpec": { ... }+        }+    ],++    // This field should be applied to the Container's OCI spec if any of the+    // devices defined above are requested on the CLI+    "containerSpec": [+        {+            "devices": [ (optional)+                {+                    "hostPath": "<path>",+                    "containerPath": "<path>",++                    // Cgroups permissions of the device, candidates are one or more of+                    // * r - allows container to read from the specified device.+                    // * w - allows container to write to the specified device.+                    // * m - allows container to create device files that do not yet exist.+                    "permissions": "<permissions>" (optional)+                }+            ]+            "mounts": [ (optional)+                {+                    "hostPath": "<source>",+                    "containerPath": "<destination>",+                    "options": "<OCI Mount Options>", (optional)+                }+            ],+            "hooks": [ (optional)+                {+                    "hookName": "<hookName>",+                    "path": "<path>",+                    "args": ["<arg>", "<arg>"], (optional)+                    "env":  [ "<envName>=<envValue>"], (optional)+                    "timeout": <int> (optional)+                }+            ]+        }+    ]+}+```++#### Specification version++* `cdiVersion` (string, REQUIRED) MUST be in [Semantic Version 2.0](https://semver.org) and specifies the version of the CDI specification used by the vendor.++#### Kind++* `kind` (string, REQUIRED) field specifies a label which uniquely identifies the device vendor.+  It can be used to disambiguate the vendor that matches a device, e.g: `docker/podman run --device vendor.com/device=foo ...`.+    * The `kind` and `kindShort` labels have two segments: a prefix and a name, separated by a slash (/).+    * The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (\_), dots (.), and alphanumerics between.+    * The prefix must be a DNS subdomain: a series of DNS labels separated by dots (.), not longer than 253 characters in total, followed by a slash (/).+    * Examples (not an exhaustive list):+      * Valid: `vendor.com/foo`, `foo.bar.baz/foo-bar123.B_az`.+      * Invalid: `foo`, `vendor.com/foo/`, `vendor.com/foo/bar`.++#### Container Runtime++* `containerRuntime` (array of string, OPTIONAL) indicates that this CDI specification targets only a specific container runtime.+  If this field is not indicated then container runtimes should consider that the JSON file targets all runtimes.+  If this field is indicated then container runtimes should only run it if one of the identifiers matches the container runtime's identifier.+  Possible values (not an exhaustive list): docker, podman, gvisor, lxc++#### CDI Devices++The `cdiDevices` field describes the set of hardware devices that can be requested by the container runtime user.+Note: For a CDI file to be valid, at least one entry must be specified in this array.++  * `cdiDevices` (array of objects, REQUIRED) list of devices provided by the vendor.+    * `name` (string, REQUIRED), name of the device, can be used to refer to it when requesting a device.+      * Beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (\_), dots (.), and alphanumerics between.+      * e.g: `docker/podman run --device foo ...`+    * `nameShort` (array of strings, OPTIONAL), alternative names for the device. Can be used to reduce the CLI verbosity+      * Entries in the array MUST use the same schema as the entry for the `name` field+    * `containerSpec` (object, OPTIONAL) this field is described in the next section.+      * This field should only be merged in the OCI spec if the device has been requested by the container runtime user.+++#### Container Spec++The `containerSpec` field describes edits to be made to the OCI specification. Currently only three kinds of edits can be made to the OCI specification: `devices`, `mounts` and `hooks`.++The `containerSpec` field is referenced in two places in the specification:+  * At the device level, where the edits MUST only be made if the matching device is requested by the container runtime user.+  * At the container level, where the edits MUST be made if any of the of the device defined in the `devices` field are requested.+++The `containerSpec` field has the following definition:+  * `devices` (array of objects, OPTIONAL) describes the device nodes that should be mounted:+    * `hostPath` (string, REQUIRED) path of the device on the host.+    * `containerPath` (string, REQUIRED) path of the device within the container.+    * `permissions` (string, OPTIONAL) Cgroups permissions of the device, candidates are one or more of:+      * r - allows container to read from the specified device.+      * w - allows container to write to the specified device.+      * m - allows container to create device files that do not yet exist.+  * `mounts` (array of objects, OPTIONAL) describes the mounts that should be mounted:+    * `hostPath` (string, REQUIRED) path of the device on the host.+    * `containerPath` (string, REQUIRED) path of the device within the container.+    * `permissions` (string, OPTIONAL) Cgroups permissions of the device, candidates are one or more of:

well you might want to do a readonly mount :) Thanks for picking up on the missing text!

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentopencontainers/runc

Move integration tests to opensuse

I was trying to say (a little clumsily) "instead of caching just bundle/rootfs, cache the entire bundle so you don't need to copy *" not that we shouldn't cache at all.

It looks like we have the same idea in mind :D ! I think the latest version reflects that, let me know if I'm completely misreading your message and the code doesn't reflect that.

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 28f66cc331d11a8b025cfc97ca7e35b2b2f237d1

Cache result of umoci unpack Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

pull request commentopencontainers/runc

Move integration tests to opensuse

cp -a is more fool-proof than cp -P (and -a implies -R) in this respect. I think the issue is that you're copying /* which can result in symlinks being resolved at the top-level of the directory. -a will preserve that.

I'll update the last commit, when I was copying stuff around, symlinks were definitely not at the root though.

But it would just be simpler to do umoci unpack $CACHED_BUNDLE and then do cp -a $CACHED_BUNDLE $BUNDLE without using * (so you don't run into spaces-in-filenames or too-many-arguments problems).

If I don't cache the result of umoci unpack I get a pretty high CI time, see https://travis-ci.org/github/opencontainers/runc/builds/703395550?utm_source=github_status&utm_medium=notification Which is the direct result of the first commit: https://github.com/opencontainers/runc/pull/2486/commits

Let me update the *, I was testing things around :)

Wild idea, maybe try running it under strace (right there on CI) to see what is going on?

Hmm yeah that would have worked too :D !

RenaudWasTaken

comment created time in 5 days

pull request commentopencontainers/runc

Move integration tests to opensuse

Looks like CI is green and no significant increase with this latest caching commit!

RenaudWasTaken

comment created time in 5 days

pull request commentcontainer-orchestrated-devices/container-device-interface

Add initial spec

Ping :)

RenaudWasTaken

comment created time in 5 days

pull request commentcontainer-orchestrated-devices/container-device-interface

Initial README

Ping :)

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha b24a5199ee4ab9c3c54727162a7b3fb9b6aad2f2

First attempt at caching Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentopencontainers/runc

Move integration tests to opensuse

Looks like a cp -R -P $cache/* "$1" yields a different result, I'm pretty sure we are dealing with some symlinks shenanigans now :D !

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 4bd8194deecb446aaf6be65162ec75c1ef46a7f7

First attempt at caching Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha ac696323efddda6a1379dd56a1a07efd35f14164

First attempt at caching Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 928b7fa5169c55f9ab984212a13fc045b887de8a

First attempt at caching Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

pull request commentopencontainers/runc

Move integration tests to opensuse

Hmm so that's now to the point where the CI exceeds the time limit, I'll see if I manage to reproduce by some other way

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/enhancements

Renaud Gaubert

commit sha 6b4b9d00f22d2e3524be3b184e17f9340e0b3457

Disable AcceleratorUsage Metrics initial kep Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

pull request commentkubernetes/kubernetes

Move pkg/kubelet/apis to k8s.io/kubelet/pkg/apis

Here is what I see after https://github.com/kubernetes/kubernetes/pull/92632 is merged:

  • resourcemetrics is alpha and might make sense to move
  • stats is alpha and might make sense to move
  • podresources is beta, is "leftover" code that will get moved in cm/podresources as a followup PR
  • config which already has a place in the staging directory (k8s.io/kubelet/config)

I'm not familiar with the config architecture but it definitely seems like it's at two places intentionally. With the pkg/kubelet/apis looking like it handles default and schema validation.

Moving these apis might be something that could be done gradually and as request for beta graduation?

michaelbeaumont

comment created time in 5 days

Pull request review commentkubernetes/kubernetes

Move external facing podresources apis to staging

 set -o nounset set -o pipefail  KUBE_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../" && pwd -P)"-POD_RESOURCES_ALPHA="${KUBE_ROOT}/pkg/kubelet/apis/podresources/v1alpha1/"

Fixed!

RenaudWasTaken

comment created time in 5 days

push eventRenaudWasTaken/kubernetes

Renaud Gaubert

commit sha f5441d55ad5de88497887d31184a234389c06daf

Move podresources api to k8s.io/kubelet/pkg/apis Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha 5e98b9cfed8353756cd6164387ae8ae433312c78

run hack/update-vendor.sh Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha 9419692342634dbe69200263958f63ab8579485e

Run gofmt Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 5 days

Pull request review commentkubernetes/kubernetes

Move external facing podresources apis to staging

 set -o nounset set -o pipefail  KUBE_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../" && pwd -P)"-POD_RESOURCES_ALPHA="${KUBE_ROOT}/pkg/kubelet/apis/podresources/v1alpha1/"

Thanks let me update that!

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/retest

RenaudWasTaken

comment created time in 5 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/label api-review

RenaudWasTaken

comment created time in 6 days

push eventRenaudWasTaken/kubernetes

Renaud Gaubert

commit sha 86f57959f5484e4f8855cbfa3cd696963c663ec3

Move podresources api to k8s.io/kubelet/pkg/apis Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha 18fbd1f57f714d6e2aee5c0d61423208a59252e3

run hack/update-vendor.sh Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha a8cb25a5b5a52169d9b7d01f9271ad62e139b0f9

Run gofmt Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/kubernetes

Renaud Gaubert

commit sha efd159f86c7bec63c97d7fce93a4ae6afc38fa2f

run hack/update-vendor.sh Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha b0a6b926fc38ccee134b4b41a469e287c26b5439

Run gofmt Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

pull request commentkubernetes/kubernetes

Add DisableAcceleratorUsageMetrics Feature Gate

/retest

RenaudWasTaken

comment created time in 6 days

pull request commentkubernetes/kubernetes

Move external facing podresources apis to staging

/assign @dims

Note that I followed the model of your PR: https://github.com/kubernetes/kubernetes/pull/83551

RenaudWasTaken

comment created time in 6 days

pull request commentkubernetes/kubernetes

Add DisableAcceleratorUsageMetrics Feature Gate

/retest

RenaudWasTaken

comment created time in 6 days

PR opened kubernetes/kubernetes

Move external facing podresources apis to staging

What type of PR is this? /kind api-change /area code-organization /sig node

What this PR does / why we need it: podresources API is external facing. Currently we are forcing folks to import them from k8s.io/kubernetes which is not optimal. We should instead make them available from the k8s.io/kubelet repo to make it easier for them.

Which issue(s) this PR fixes:

Special notes for your reviewer: Note, for people who will be broken by this change (i.e: people pulling from kubernetes master), they can either: a) Freeze the kubernetes version they rely on, which they already should, in the go.mod they should have something along the lines of

require (
        ...
	k8s.io/kubernetes v0.17.4
        ....
)

b) Change the import path:

sed -i 's#k8s.io/kubernetes/pkg/kubelet/apis/podresources/v1alpha1#k8s.io/kubelet/pkg/apis/podresources/v1alpha1#g" *.go
go mod tidy

/cc @dashpole @derekwaynecarr

Does this PR introduce a user-facing change?:

external facing API podresources is now available under k8s.io/kubelet/pkg/apis/
+29 -29

0 comment

27 changed files

pr created time in 6 days

create barnchRenaudWasTaken/kubernetes

branch : move-podresources-api

created branch time in 6 days

pull request commentkubernetes/kubernetes

Add DisableAcceleratorUsageMetrics Feature Gate

/retest

RenaudWasTaken

comment created time in 6 days

push eventRenaudWasTaken/kubernetes

Renaud Gaubert

commit sha 16c1b559ab930a7b9f2d3ebf39929566f41911bc

Add the DisableAcceleratorUsageMetrics feature gate Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

Pull request review commentkubernetes/enhancements

Disable AcceleratorUsage Metrics initial kep

+# Disable AcceleratorUsage Metrics++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+    - [Alpha Graduation](#alpha-graduation)+    - [Alpha -&gt; Beta Graduation](#alpha---beta-graduation)+    - [Beta -&gt; GA Graduation](#beta---ga-graduation)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature enablement and rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+<!-- /toc -->++## Release Signoff Checklist++- [X] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements](https://github.com/kubernetes/enhancements/issues/1867)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [X] (R) Design details are appropriately documented+- [X] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [X] (R) Graduation criteria is in place+- [X] (R) Production readiness review completed+- [ ] Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++This KEP outlines the process to deprecate the Accelerator Metrics collected by Kubelet.++Accelerator metrics are no longer expected to collected by Kubelet, but by external monitoring agents using the PodResources API.+The purpose of creating that API was to provide an out of tree mechanism for all vendors to provide device specific metrics.+This allows them to provide these metrics without requiring them to make changes to Kubernetes.++Now that this API is beta and soon to be G.A, this KEP outlines the process to deprecate metrics that were added before sig-node conveged on the PodResources API.++## Motivation++### Goals++Deprecate and remove the AcceleratorUsage metrics that kubelet currently advertises.++### Non-Goals++Deprecation and removal of the summary API is certainly a goal of sig-node, and the step of removing the AcceleratorUsage metric is a step in that direction (agreed upon goal with incremental steps towards it) but not the goal of this KEP.++## Proposal++### Risks and Mitigations++The main risk that we face is breaking existing consumers of the AcceleratorUsage metrics.+The way this risk is mitigated is through the use of Feature Flags, which allows users to re-enable this metric.+We will also be pointing in documentation users towards the newer and richer method of collecting metrics.++Note that we don't know who are the consumers of that metric but we suspect that this will impact a small subset of users as these metrics on NVIDIA GPU utilization are often unreliable and very coarse.++## Design Details++Add a feature flag and pass the disable option to cadvisor.++### Test Plan++* E2E tests that checks when the feature flag is enabled if the metrics are present or not.++### Graduation Criteria++#### Alpha Graduation++* Feature Flag is present.+* E2E tests are implemented.+* Documentation has been published on how to transition to the new metrics.+* Release Notes have been created and promote immediate usage of that flag.++#### Alpha -> Beta Graduation++* Sufficient heads up has been given (1 year) to users.

ping @derekwaynecarr @dchen1107

Thanks !

RenaudWasTaken

comment created time in 6 days

pull request commentkubernetes/enhancements

Disable AcceleratorUsage Metrics initial kep

The PR is ready to go, @dashpole should we figure out the beta graduation strategy in the next release? This would allow us to:

  • Merge the KEP
  • File for the exception process
  • Merge the Feature PR

What do you think?

RenaudWasTaken

comment created time in 6 days

push eventRenaudWasTaken/kubernetes

David Ashpole

commit sha fca84c02bb5a089d071e608a200b7dc5dc79d074

add dashpole as kubelet approver

view details

Aresforchina

commit sha 2293b473464a78877a57bdfff5a2b0f11c3283bf

add some comments for const variable

view details

Kewei Ma

commit sha 34fce9faee46e38adf55255a77188120f2567d03

Fix a comment in job_controller

view details

Manuel Rüger

commit sha eb6c7169276a1978b851deafb25b507caf696ac4

PodTolerationRestriction: Mention Whitelist Scope in Error Currently it's not clear if the issue came from the namespace whitelist of if the namespace whitelist was not applied at all (i.e. via a misspelled annotation). This makes the error more explicit if the pod tolerations caused a conflict with cluster-level or namespace-level whitelist. Signed-off-by: Manuel Rüger <manuel@rueg.eu>

view details

Lukasz Szaszkiewicz

commit sha fbb1f23735aa26c61305ff1337a02a8add830142

kube-aggregator: changes the name of aggregator_unavailable_apiservice_count metrics

view details

mattjmcnaughton

commit sha f5080850fc7fd1997cb8c0be32a3f4e0e26b9c23

Delete TODO in `image_gc_manager` I think the TODO here may have actually been unnecessary. There isn't a ton of interest around merging https://github.com/kubernetes/kubernetes/pull/87425, which contains a fix. Delete the TODO so we don't devote time to working on this area in the future.

view details

YuikoTakada

commit sha a80564dbdd87f088be09e516e4a2f69e78bfd42f

Fix non-ascii characters in pkg/kubelet/qos/doc.go

view details

Sergey Yedrikov

commit sha e5370afba2842b844699b239f3f14306f9923eb6

Fix for kubectl issue 834: "kubectl help api-resources --sort-by" text mentions nodes, not API resources

view details

Laszlo Janosi

commit sha 1c393c73a63fedbcd041f21cc1a9a59de83167cb

Change SCTPSupport default value to true

view details

Łukasz Osipiuk

commit sha 02915ef1797681d2f51019a46989e9ec597d294a

Remove endpoints RBAC for Cluster Autoscaler

view details

Benjamin Danon

commit sha 77ca434ec378d607fee83dc790eb8981d5beb4e7

Fix the newName field name in the example

view details

Benjamin Danon

commit sha c39c64ffdaf677d09c412e7447b5bf400394068b

Fix the newName field name in the page

view details

Claudiu Belu

commit sha 2321378fe5ebc2d376135635f3ee011ee4a2c90a

test images: Adds OWNERS files for images (part 3) Adds reviewers to the OWNERS files in the kubernetes/test/images folder. The reviewers are added automatically, based on their contributions on an image (>= 20% code churn). Note that the code churn is taken into account for authors, and not committers. Adds OWNERS files for: cuda-vector-add, nonewprivs, pets, redis, volume.

view details

Kenjiro Nakayama

commit sha 18856dace935db46d3ba84374ce23438922e272b

Add DNS1123Label validation to IsFullyQualifiedDomainName func This patch adds IsDNS1123Label validation to IsFullyQualifiedDomainName func. Even when one label is longer than 64 characters, the current validation does not validate it. Hence this patch adds the label check and do not allow invalid domain.

view details

Brian Pursley

commit sha 99f6dca1a8d1ea64d22a68263c77bcafd6fedc48

Added kubectl apply check to prevent using --dry-run=server with --force

view details

Antonio Ojea

commit sha cb87793d57f59b9ead730fb1e4ed6cfa38c189f2

Add unit test to portallocator storage Add unit test for the portallocator storage based on the ipallocator ones. pkg/registry/core/service/ipallocator/storage/storage_test.go

view details

Antonio Ojea

commit sha e3df13439a72888cd83ed9896359d75e1787d2fc

fix service allocation concurrency issues The service allocator is used to allocate ip addresses for the Service IP allocator and NodePorts for the Service NodePort allocator. It uses a bitmap backed by etcd to store the allocation and tries to allocate the resources directly from the local memory instead from etcd, that can cause issues in environment with high concurrency. It may happen, in deployments with multiple apiservers, that the resource allocation information is out of sync, this is more sensible with NodePorts, per example: 1. apiserver A create a service with NodePort X 2. apiserver B deletes the service 3. apiserver A creates the service again If the allocation data of apiserver A wasn't refreshed with the deletion of apiserver B, apiserver A fails the allocation because the data is out of sync. The Repair loops solve the problem later, but there are some use cases that require to improve the concurrency in the allocation logic. We can try to not do the Allocation and Release operations locally, and try instead to check if the local data is up to date with etcd, and operate over the most recent version of the data.

view details

Dr. Stefan Schimanski

commit sha d42ccdc690f617cd55da0e3f699194e1dc247895

Add myself to staging repo SECURITY_CONTACTS

view details

Gaurav Singh

commit sha 862c30a2284a54a8c91778828b41f157b6a506ec

[Provider/Azure] optimize mutex locks

view details

Brian Pursley

commit sha b88dbbb4906497b921558bd078ca70478ff69234

Added unit tests documenting current behavior of tableConverter

view details

push time in 6 days

push eventRenaudWasTaken/kubernetes

Renaud Gaubert

commit sha f00561869326fe279b2046e361ad8f7ef6dc5abd

Add the DisableAcceleratorUsageMetrics feature gate Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha d1fa99088068f523a10ad8fb9a0abdd9d777312d

Move integration tests to opensuse Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

Pull request review commentopencontainers/runc

Move integration tests to opensuse

 function check_cpu_shares() { @test "update cgroup cpu limits" {     [[ "$ROOTLESS" -ne 0 ]] && requires rootless_cgroup -    # run a few busyboxes detached+    # run a few containeres detached

I took a stab at it and removed most of the references.

Looking back, I think this is probably a broader topic that should be tackled outside this PR. A lot of the comments are very similar in that they convey only the intent of the next line which is usually pretty obvious:

# Start the command.
runc start test_container

# Kill the container.
runc kill test_container KILL

# check state
testcontainer test_container running

# test state of container is paused
testcontainer test_container paused

Overall this seems like a discussion that's pretty close to a coding style discussion and might have a better place in an issue first so that there's consensus on how this should be addressed :)

What do you think?

RenaudWasTaken

comment created time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha ab065fe2d6ff83ea9aed4eba401da97a4ae4299e

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

pull request commentopencontainers/runc

Move integration tests to opensuse

I've been fighting with the CI for a few days now :D !

I think I'm almost done, the most significant change that I've had to introduce is that it seems that just copying the rootfs that umoci extracts hangs in Vagrant (but not in the dockerfile). See an example here: https://travis-ci.org/github/opencontainers/runc/jobs/701939941 I tracked it down, through plain dumb comment bisecting and CI runs to the specific copy instruction: https://github.com/opencontainers/runc/blob/1b94395c06577b36bae4afd2fe5da229f7a03284/tests/integration/helpers.bash#L454

I suspect it's due to the opensuse image since that issue isn't showing up in master and wasn't showing up when using the debian image. Unfortunately I don't have a Vagrant capable machine so I haven't been able to thoroughly debug it (I suspect symlink shenanigans).

The workaround that I've employed is to unpack the rootfs (umoci unpack) for every test, but this has introduced a noticeable 2x-2.5x increase in the CI. e.g:

  • Fedora takes 50 minutes instead of 20 minutes
  • Go takes 20 minutes instead of 10 minutes
  • cgroup systemd takes 6 minutes instead of 3 minutes
RenaudWasTaken

comment created time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 5a6f818db3845c5f6990654ae302d50a8e6ac4a8

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

PR closed NVIDIA/gitlab-answer-app

Test change

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+2 -0

1 comment

1 changed file

RenaudWasTaken

pr closed time in 6 days

push eventNVIDIA/gitlab-answer-app

Renaud Gaubert

commit sha b265d0fd6c41fe595bc0ea8cd303f80a8f1fbf21

Use checkbox in message Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

Renaud Gaubert

commit sha fc76fbb655eeadb1c73a9e4a525b85865796f1fe

[README] Update deployment instructions Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

PR opened NVIDIA/gitlab-answer-app

Test change

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+2 -0

0 comment

1 changed file

pr created time in 6 days

PR closed NVIDIA/gitlab-answer-app

Test change

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+2 -0

0 comment

1 changed file

RenaudWasTaken

pr closed time in 6 days

push eventNVIDIA/gitlab-answer-app

Renaud Gaubert

commit sha 49c52513cf026616b08bdba2c36bef6c746a5b27

Use pull_request instead of pull_requests Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

PR opened NVIDIA/gitlab-answer-app

Test change

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+2 -0

0 comment

1 changed file

pr created time in 6 days

PR closed NVIDIA/gitlab-answer-app

Test change

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+2 -0

0 comment

1 changed file

RenaudWasTaken

pr closed time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha b0d464720cdfff594483479dabb6b6ccd128e7a7

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 258a25c79361c8933b1eedec130666693ed1dd45

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha f747f577afd89f2902485158b2a213a6ecd97e27

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 2482559904e3b73a5693657961694f10e23f0310

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha f6c39df421b3efcd095496211e7468bc0eb6728d

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha a85bce62d993357ba96c2e1ef9ba2c8334dcc20b

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 58f8b167ea2c21c1211d571b59c271a66f82224f

Testing the CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha d884147e2890076a878c29627c1db6db734dd5f6

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha b541f726d01d9e1c4a2b47c4fd5cc662161b6312

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 6 days

Pull request review commentopencontainers/runc

Move integration tests to debian

 func TestSeccompDenyGetcwdWithErrno(t *testing.T) { 		t.Fatalf("Getcwd should fail with negative exit code, instead got %d!", exitCode) 	} -	expected := "pwd: getcwd: No such process"+	expected := "getcwd: cannot access parent directories: No such process" 	actual := strings.Trim(buffers.Stderr.String(), "\n")-	if actual != expected {-		t.Fatalf("Expected output %s but got %s\n", expected, actual)+	if !strings.Contains(actual, expected) {+		t.Fatalf("Expected output to contain `%s` but got `%s`\n", expected, actual)

Thanks addressed (and in other parts of the code)!

RenaudWasTaken

comment created time in 7 days

Pull request review commentopencontainers/runc

Move integration tests to debian

 import ( 	"github.com/sirupsen/logrus" ) -// init runs the libcontainer initialization code because of the busybox style needs+// init runs the libcontainer initialization code because of the debian style needs

Thanks addressed!

RenaudWasTaken

comment created time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha bd833d4f718019840708d662927599622172a0cd

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 72839ce84f8b5cfa8cbe7ff0d747532380182b3a

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

Pull request review commentopencontainers/runc

Move integration tests to debian

 func TestSeccompDenyGetcwdWithErrno(t *testing.T) { 	} 	ps, err := pwd.Wait() 	if err == nil {-		t.Fatal("Expecting error (negative return code); instead exited cleanly!")+		t.Fatalf("Expecting error (negative return code); instead exited cleanly!")

Yep thanks for spotting this, I changed it while debugging :) !

RenaudWasTaken

comment created time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 45685bcc5358186fd5878fae1ff36c84f50d171f

Move integration tests to debian Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha f97a02fe6a1bba2881c53db87bc0a3183cef4930

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha f86a517942ea0fb17a2409ed0e14bb5b67b161e8

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha faef61e4ed12e3517db8ca57288a051b66997f6d

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 29a3964c582b0e7a6100bc242da3de776a52c671

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha ce312d2b838317f1f6dd76896e82ffc9e636d5de

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 8ebb9021dfcef825398e1fd0330c061854f1aed8

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha f31c27fbc293c4a68eb8cb8f659160956c06216e

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 7e62848c9d28eaea4b3a14ae136baaf47ca085c1

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha cc07cd008b80a7dd05091221d3024017c8a3879f

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha 02156aabda339314a457aea17870656a4ab140d3

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha a3023cb1a16e3d481aea0ec68af986c7588bc7ad

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 7 days

push eventNVIDIA/k8s-device-plugin

Kevin Klues

commit sha 813a6f0c94685a8cca5b9b3cbc3e924634d29bf1

Add the ability to set 'resources' as part of a helm install Signed-off-by: Kevin Klues <kklues@nvidia.com>

view details

Renaud Gaubert

commit sha 0bdfc3b8fbb7f4d228d514040e148dba93a1eff1

Merge branch 'upstream-helm-set-resources' into 'master' Add the ability to set 'resources' as part of a helm install See merge request nvidia/kubernetes/device-plugin!34

view details

push time in 9 days

push eventRenaudWasTaken/runc

Renaud Gaubert

commit sha d880b402b375778f9062df8d624e09879570e05c

Log CI Signed-off-by: Renaud Gaubert <rgaubert@nvidia.com>

view details

push time in 10 days

PR opened container-orchestrated-devices/container-device-interface

Add initial spec

This Pull Request adds an initial Specification to CDI.

Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+191 -0

0 comment

1 changed file

pr created time in 10 days

PR opened container-orchestrated-devices/container-device-interface

Reviewers
Initial README

This Pull Request adds an initial README to cdi.

/cc @mrunalp Signed-off-by: Renaud Gaubert rgaubert@nvidia.com

+74 -0

0 comment

1 changed file

pr created time in 10 days

create barnchRenaudWasTaken/container-device-interface

branch : initial-spec

created branch time in 10 days

create barnchRenaudWasTaken/container-device-interface

branch : readme

created branch time in 10 days

more