Handle networks.driver_opts for a service

[robmry]

- What I did

Handle networks.driver_opts for a service.

Related to:

• Add driver_opts to services.networks compose-spec/compose-spec#498
• Per-interface sysctls moby/moby#47686

These are endpoint-specific driver options...

services:
  myservice:
    networks:
      mynet:
        driver_opts:
          "option1": "value1"

The API has had support for a long time, it's only recently been added to compose (unreleased right now).

- How I did it

Updated verification schema, add ServiceNetworkConfig.DriverOpts, passed the opts to swarm, and updated tests.

- How to verify it

Updated tests.

With this config:

services:
  foo:
    image: alpine
    command: sleep infinity
    networks:
      mynet:
        driver_opts:
          "com.docker.network.endpoint.sysctls": "net.ipv6.conf.IFNAME.accept_ra=1"

networks:
  mynet:
    name: mynet

Ran docker stack deploy --compose-file compose.yml foo ... checked that the option appeared in the container's inspect output, and the sysctl was updated in the container.

- Description for the changelog

Added support to `docker stack deploy` for `driver_opts` in a service's networks, in new version 3.13 of its compose schema.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.35%. Comparing base (9b61bbb) to head (94f9de5).
Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5125      +/-   ##
==========================================
- Coverage   61.37%   61.35%   -0.03%     
==========================================
  Files         298      295       -3     
  Lines       20717    20717              
==========================================
- Hits        12715    12710       -5     
- Misses       7102     7104       +2     
- Partials      900      903       +3     

[robmry]

I put this into schema file v3.12 to get things going ... but perhaps should have created a new version?

(I'm not sure what the version is used for - but this isn't a new API field, just new to the compose spec. So, the new field will be handled by old engines, even if they don't understand specific driver options - it just won't appear in older compose files.)

[thaJeztah]

Yes, we probably should do a new version (but we made the version field optional to automatically pick "latest"

To add a new version, it's good to do in 2 commits;

• 1 commit that makes a copy of the previous version (no changes)
• 1 commit that updates the schema

That way it's easier to see the changes that were introduced in the new version

I think there's a couple of other fields we should add (some of those to be "stubs") so that we're more compatible with the compose-spec; until we have time to work on planning the actual migration to the compose-spec (which may need some more work).

We can discuss tomorrow if you have some time then

[robmry]

Thank you ... I've added a v3.13 and made the changes there.

[thaJeztah]

LGTM

[laurazard]

LGTM