Feature #11255

[Crunchv2] Option to use host networking for containers

Added by Peter Amstutz 4 months ago. Updated 4 months ago.

Status:ResolvedStart date:03/21/2017
Priority:NormalDue date:
Assignee:Peter Amstutz% Done:

100%

Category:-
Target version:2017-03-29 sprint
Story points0.5Remaining (hours)0.00 hour
Velocity based estimate-

Description

Docker bridge networking has bugs on certain kernels. Add a flag to crunch-run to instruct containers to use host networking instead of the default bridge network.

Intend to support the following use case: the entire cluster is running compute nodes which will use host networking instead of bridge networking.

Sysadmin will specify the option via command line (which can be configured in crunch-dispatch-slurm).

We will provide two options:

  • Use host networking when networking is enabled, and "none" when it is disabled.
    When a container is created with --net=none, the container is given an "empty" network namespace (only the loopback device is available.) If kernel bugs are associated with Docker's bridge networking, this option would use host networking for those containers that need it, while maintaining isolation for containers that don't need networking.
  • Use host networking for all containers.
    If kernel bugs make network namespaces totally unusable, always use --net=host, so that network namespaces are not used at all. This should sidestep the issue, at the expense of reduced isolation from the host system.

Subtasks

Task #11312: Review 11255-docker-host-networkingResolvedPeter Amstutz

Associated revisions

Revision ae970cb1
Added by Peter Amstutz 4 months ago

Merge branch '11255-docker-host-networking' closes #11255

History

#1 Updated by Peter Amstutz 4 months ago

  • Description updated (diff)

#2 Updated by Tom Morris 4 months ago

  • Target version set to 2017-03-29 sprint

#3 Updated by Tom Morris 4 months ago

  • Story points set to 0.5

#4 Updated by Tom Clegg 4 months ago

  • Assignee set to Nico César
  • Target version changed from 2017-03-29 sprint to 2017-04-12 sprint

#5 Updated by Nico César 4 months ago

summon Nico before discussing implementing

#6 Updated by Peter Amstutz 4 months ago

  • Description updated (diff)

#8 Updated by Peter Amstutz 4 months ago

  • Description updated (diff)

#9 Updated by Peter Amstutz 4 months ago

  • Target version changed from 2017-04-12 sprint to 2017-03-29 sprint

#10 Updated by Peter Amstutz 4 months ago

  • Status changed from New to In Progress
  • Assignee changed from Nico César to Peter Amstutz

#11 Updated by Peter Amstutz 4 months ago

  • Description updated (diff)
  • Status changed from In Progress to New
  • Assignee changed from Peter Amstutz to Nico César
  • Target version changed from 2017-03-29 sprint to 2017-04-12 sprint

#12 Updated by Peter Amstutz 4 months ago

  • Target version changed from 2017-04-12 sprint to 2017-03-29 sprint

#13 Updated by Peter Amstutz 4 months ago

  • Status changed from New to In Progress
  • Assignee changed from Nico César to Peter Amstutz

#14 Updated by Tom Clegg 4 months ago

11255-docker-host-networking @ bfd73917834d89e9e8c55b6bb4e05912741fbf8a

I think the flag docs should say "for containers with networking enabled" instead of "when API: true". Even though that happens to be the only case where we enable networking right now, the flag really makes sense in terms of networking, not API access.

(from chat) (10:59:03 AM) tom: Still seems to me we might as well offer that option in a way that isn't necessarily bundled with the "lose ability to turn off networking" sacrifice... we can make two options that do separate meaningful things, and document the kernel bug workaround as "use both of these options at once and you should be OK"

Specifically how about the following orthogonal options
  1. Use specified network mode when enabling network access (default "default")
  2. Enable network access for all containers regardless of what's specified in runtime constraints
I think this would make it easier to see what each flag does, and make it possible to do things like
  • always enable networking, but use default networking mode
  • use "bridge" networking mode regardless of what the docker default is (in case this can change)
  • use some other docker networking mode we don't know about yet

The combination of flags needed for the old-kernel workaround should be documented at http://doc.arvados.org/install/crunch2-slurm/install-dispatch.html

#15 Updated by Peter Amstutz 4 months ago

11255-docker-host-networking updated:

-container-enable-networking=[default, always]

-container-network-mode=[any valid docker network mode, passed through to container creation]

Didn't update documentation yet, will do.

#16 Updated by Tom Clegg 4 months ago

flag help messages should probably just indent with tabs instead of a combination of spaces and tabs. The rest LGTM, thanks.

#17 Updated by Peter Amstutz 4 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:ae970cb115251915c0a8e1052b23acdd2ab70fee.

Also available in: Atom PDF