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

[Windows] Support for isolation mode on container spec #2342

Merged
merged 2 commits into from
Oct 6, 2017

Conversation

simonferquel
Copy link
Contributor

This adds an "isolation" field to the container spec, so that isolation mode (process, hyperv) can be decided per service instead of globally for a node.

@codecov
Copy link

codecov bot commented Aug 8, 2017

Codecov Report

Merging #2342 into master will decrease coverage by 0.01%.
The diff coverage is 70%.

@@            Coverage Diff             @@
##           master    #2342      +/-   ##
==========================================
- Coverage   60.62%   60.61%   -0.02%     
==========================================
  Files         128      128              
  Lines       26309    26319      +10     
==========================================
+ Hits        15951    15953       +2     
- Misses       8954     8965      +11     
+ Partials     1404     1401       -3

@aluzzardi
Copy link
Member

Hey @simonferquel - why do we need to change the import path for logrus?

And if we do need to change it - why update all the dependencies in vendor.conf rather than just logrus?

@simonferquel
Copy link
Contributor Author

The problem is that moby/moby has already updated logrus import path and it is forbidden to import 2 different packages that only have casing differences in their import path... so we need to update it in swarmkit (to be able to revendor it in moby), and we need to depend on components that are their logrus import path updated... same thing apply to cli, notary, ucp, swarm classic...

Sent from my Samsung SM-G935F using FastHub

@simonferquel simonferquel force-pushed the swarm-service-isolation branch 2 times, most recently from 28d2d26 to 95380b7 Compare August 28, 2017 10:04
@simonferquel
Copy link
Contributor Author

This has just been rebased. cc @aluzzardi

@thaJeztah
Copy link
Member

ping @nishanttotla @dperny @stevvooe @johnstep PTAL

api/specs.proto Outdated
@@ -298,6 +298,11 @@ message ContainerSpec {
oneof init {
bool init_value = 23;
}

// Isolation defines the isolation level for engines supporting multiple isolation modes
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like we need an enum here, according to swarmkit's style.

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 considered that, but after a bit of thinking, it felt that valid values for isolationMode might ultimately depend on the underlying container runtime. For now only dockerd on Windows support different values, but it might change, and we might even require a non fixed set of values.
For exemple, I foresee that with lcow, we might have at some point values like: hyperv{<something identifying a specific linuxkit/Ubuntu/whatever version>}

Additionaly, isolationMode is a config setting specific to the container runtime, and has no effect on swarm scheduling. So I don't think we should put validation logic at the swarmkit level here

Copy link
Contributor

Choose a reason for hiding this comment

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

@simonferquel The validation consideration here is a valid point and perhaps we could have made this more flexible, but we found that much of the input on the docker side was weakly validated and lead to challenging errors to diagnose in an orchestration system. By ensuring that input is correct, we can eliminate these errors, at the cost of being very literal.

api/api.pb.txt Outdated
@@ -5413,6 +5434,14 @@ file {
type_name: ".docker.swarmkit.v1.NodeRole"
json_name: "role"
}
field {
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this was missed in another PR.

@simonferquel
Copy link
Contributor Author

well it is specific to the runtime adapter, not the runtime itself. But one thing still remains: for example containerd on windows allows to specify a different hypervUtilityVMPath than default. The containerd adapter could eventually parse the isolation mode field to override the utility VMPath

@simonferquel
Copy link
Contributor Author

I added a commit with an enum. @stevvooe, let me know if you prefer the code with or without it

api/specs.proto Outdated
option (gogoproto.goproto_enum_prefix) = false;

// Default uses whatever default value from the container runtime
Default = 0 [(gogoproto.enumvalue_customname) = "ContainerIsolationDefault"];
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use all caps for enums. See the TaskState for an example of enum style. Remember that these are scoped to the package from protobufs perspective, so they should be prefixed:

ISOLATION_DEFAULT
ISOLATION_PROCESS

The Go names you have in place are perfect.

@stevvooe
Copy link
Contributor

stevvooe commented Sep 22, 2017

@simonferquel Thanks!

There is just one more naming tweak, which needs to be done because of the way protobuf enums are namespaced.

@simonferquel
Copy link
Contributor Author

Fixed and rebased. Not sure why CI failed though (seem unrelated)
cc @stevvooe

api/specs.proto Outdated
option (gogoproto.goproto_enum_prefix) = false;

// DEFAULT uses whatever default value from the container runtime
DEFAULT = 0 [(gogoproto.enumvalue_customname) = "ContainerIsolationDefault"];
Copy link
Contributor

Choose a reason for hiding this comment

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

These need to be ISOLATION_DEFAULT, ISOLATION_PROCESS and ISOLATION_HYPERV.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry about that, just amended my last commit

@stevvooe
Copy link
Contributor

stevvooe commented Oct 2, 2017

LGTM

Copy link
Contributor

@anshulpundir anshulpundir left a comment

Choose a reason for hiding this comment

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

Looks fine to me but @nishanttotla should also take a look.

@thaJeztah
Copy link
Member

@simonferquel can you rebase (again)?

For executors supporting multiple isolation levels (ie: Docker API on
Windows), added an "isolation" field in the container spec, so that we
can schedule services with different isolation modes than the system
defaults

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
@simonferquel
Copy link
Contributor Author

@thaJeztah just rebased / push

I'll have to work a bit on the moby / cli PRs once it is merged, to adapt to the move to enums

Copy link
Contributor

@nishanttotla nishanttotla left a comment

Choose a reason for hiding this comment

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

LGTM

@nishanttotla
Copy link
Contributor

@simonferquel is there more you're planning to add to this PR, or can we merge it?

@simonferquel
Copy link
Contributor Author

@nishanttotla i am good with it.

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

Successfully merging this pull request may close these issues.

None yet

6 participants