containerd-stress utility needs to be able to run with snapshotter
passed by user in cli in order to be able to stress test snapshotters.
This adds a cli option --snapshotter="<snapshotter-name>"
Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
full diff: https://github.com/containernetworking/plugins/compare/v0.8.6...v0.9.1
changes in vendored code:
- (in containernetworking/plugins): Fix race condition in GetCurrentNS
- (in containernetworking/cni): tighten up plugin-finding logic
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If mkfs on device mapper thin pool fails, it will show pool status
as returned by dmsetup for enahnced error reporting.
Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
This parallels the implementation of windowsDiff.Apply, including
bouncing very briefly though archive.WriteDiff and then straight back
out into Windows-specific code.
It's mostly pulling existing mechanisms from non-Windows Compare or
Windows Apply, and highlights that there's probably a lot of scope for
refactoring on top of this.
Now the export-related integration tests pass CI on Windows.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
ForceRemoveAll has special logic on Windows for cleaning up a Windows
snapshotter directory. The logic was missing proper handling for an
error case that can be returned in some cases.
This fixes the CI failure seen in #5326.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
Looks like we had our own copy of the "getDevices" code already, so use
that code (which also matches the code that's used to _generate_ the spec,
so a better match).
Moving the code to a separate file, I also noticed that the _unix and _linux
code was _exactly_ the same (baring some `//nolint:` comments), so also
removing the duplicated code.
With this patch applied, we removed the dependency on the libcontainer/devices
package (leaving only libcontainer/user).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(this was introduced in 44240116aa)
Setting the oom-score-adj to -1000 is only possible if the parent process
either has no score set, or if the score is set to -1000.
However, the current implementation of GetOOMScoreAdj conflates situations
where either _no_ oom-score is set, _or_ oom-score is set, but set to 0.
In the latter case, the test would fail:
--- FAIL: TestSetOOMScoreBoundaries (0.01s)
oom_linux_test.go:79: assertion failed: 0 (adjustment int) != -1000 (OOMScoreAdjMin int)
FAIL
To prevent failures in this situation, skip that part of the test in the
above situation.
Also update the description of GetOOMScoreAdj to clarify its behavior.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
