Skip to content

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

Merged
nishanttotla merged 2 commits intomoby:masterfrom
simonferquel:swarm-service-isolation
Oct 6, 2017
Merged

[Windows] Support for isolation mode on container spec#2342
nishanttotla merged 2 commits intomoby:masterfrom
simonferquel:swarm-service-isolation

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.

@simonferquel simonferquel force-pushed the swarm-service-isolation branch from f60599b to 9fc4043 Compare August 7, 2017 15:32
@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
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.

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 simonferquel force-pushed the swarm-service-isolation branch from 07d1018 to 554fefa Compare September 22, 2017 09:46
@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 simonferquel force-pushed the swarm-service-isolation branch from 5d7e1e9 to 32e891d Compare September 22, 2017 13:43
@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

@simonferquel simonferquel force-pushed the swarm-service-isolation branch from 6360312 to 6b6688f Compare October 2, 2017 08:30
@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 simonferquel force-pushed the swarm-service-isolation branch from 6b6688f to 7d10d60 Compare October 5, 2017 10:13
@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.

6 participants