Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --device support for Windows #37638

Merged
merged 1 commit into from
Nov 27, 2018
Merged

Add --device support for Windows #37638

merged 1 commit into from
Nov 27, 2018

Conversation

jterry75
Copy link
Contributor

Implements the --device forwarding for Windows daemons. This maps the physical
device into the container at runtime.

Ex:

docker run --device="class/"

Signed-off-by: Justin Terry (VM) [email protected]

@jhowardmsft - FYI

Copy link
Member

@lowenna lowenna left a comment

Choose a reason for hiding this comment

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

Couple of minor nits for strings. Code LGTM

daemon/oci_windows.go Outdated Show resolved Hide resolved
daemon/oci_windows.go Outdated Show resolved Hide resolved
@lowenna
Copy link
Member

lowenna commented Aug 14, 2018

@johnstep PTAL

@codecov
Copy link

codecov bot commented Aug 14, 2018

Codecov Report

Merging #37638 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #37638      +/-   ##
==========================================
- Coverage   36.12%   36.08%   -0.04%     
==========================================
  Files         610      610              
  Lines       45244    45234      -10     
==========================================
- Hits        16343    16323      -20     
- Misses      26660    26669       +9     
- Partials     2241     2242       +1

@jterry75
Copy link
Contributor Author

@johnstep - All CI has passed except experimental which failed due to Swarm (unrelated in any way to this change that I can tell). Mind taking another look?

@johnstep
Copy link
Member

I cannot find the failed build on Jenkins, after it was restarted, but it might have been one of the known flaky tests., possibly DockerSwarmSuite.TestSwarmClusterRotateUnlockKey in the list here: #37306.

@jterry75
Copy link
Contributor Author

jterry75 commented Nov 5, 2018

@jhowardmsft @johnstep - I made a mistake in the vendor release on HCSShim for v0.7.9-1 that I have now corrected. But I have no code changes here to restart the builds. Can you do that for me?

@lowenna
Copy link
Member

lowenna commented Nov 6, 2018

@jterry75 Restarted, but unfortunately needs another rebase

@jterry75
Copy link
Contributor Author

jterry75 commented Nov 6, 2018

I am going to have to make a new release of hcsshim. I didn't realize you had an outstanding merge. Will rebase this AM

@jterry75
Copy link
Contributor Author

jterry75 commented Nov 7, 2018

@jhowardmsft - z failed with: FAIL: docker_api_swarm_test.go:296: DockerSwarmSuite.TestAPISwarmLeaderElection which is unrelated to this change. windowsRS5-process failed with: ERROR: Failed 'ERROR: Failed to load c:\baseimages\windowsservercore.tar into daemon under test' at 11/07/2018 00:01:17 again unrelated. Are we good with this change?

@lowenna
Copy link
Member

lowenna commented Nov 8, 2018

RS5 CI is hawked at the moment. Investigating why. Restarting the other jobs - failures are unrelated.

Copy link
Member

@lowenna lowenna left a comment

Choose a reason for hiding this comment

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

LGTM

@lowenna
Copy link
Member

lowenna commented Nov 8, 2018

@johnstep PTAL

Copy link
Member

@johnstep johnstep left a comment

Choose a reason for hiding this comment

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

Looks good, but see a couple comments. Thanks!

libcontainerd/client_local_windows.go Show resolved Hide resolved
libcontainerd/client_local_windows.go Show resolved Hide resolved
Implements the --device forwarding for Windows daemons. This maps the physical
device into the container at runtime.

Ex:

docker run --device="class/<clsid>" <image> <cmd>

Signed-off-by: Justin Terry (VM) <[email protected]>
@jterry75
Copy link
Contributor Author

@johnstep - PTAL. After adding the errors checks you requested we do need the len(spec.Windows.Devices) > 0 check so this should pass CI now.

@johnstep
Copy link
Member

Looks good.

// AssignedDevice represents a device that has been directly assigned to a container
//
// NOTE: Support added in RS5
type AssignedDevice = schema1.AssignedDevice
Copy link
Member

@thaJeztah thaJeztah Nov 27, 2018

Choose a reason for hiding this comment

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

I just noticed the -1 in this release, and wondered why; that's when I noticed this was added in v0.7.9-1 https://github.com/Microsoft/hcsshim/blob/v0.7.9-1/interface.go#L20-L23, but;

Curious; was it not possible to either update to (e.g.) a new v0.7.x version (v0.7.14), or update to v0.8.x? (I assumed the hcsshim repository used SemVer, so updating to newer patch releases wouldn't break things)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately hcsshim was not using SymVer correctly at the time of these releases. The minimal change to docker was to make this spot fix to the v0.7.9 release + this one commit. This change is already part of master in the v0.8.x releases as you see and the v0.8.x releases are properly using SymVer from now on. When we update docker to one of those releases (much bigger change) we will no longer need this spot fix.

Copy link
Member

Choose a reason for hiding this comment

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

Well, strictly it's still 0.x, so breaking changes are allowed 😅

My concern was that if there's bugfixes in hcsshim, and more recent (0.7.x) versions have breaking changes, we wouldn't be able to update to those versions, unless those fixes are backported to (e.g.) v0.7.12-2.

Are there any breaking changes between v0.7.12 and v0.7.14 that currently prevent us from updating to the latest 0.7.x version? microsoft/hcsshim@v0.7.9...v0.7.14

If there are; are those changes addressable in the moby codebase?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jhowardmsft - Is likely better equip to answer that question. My assumption is that if we need a v0.7 release we will have to carry this fix as you say. But hopefully when @jhowardmsft is ready we will just move to the v0.8.x releases. I am not aware of any breaking changes for the v1 API's that Docker uses

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants