Epic: Backwards-incompatible changes to the Compose file format

[aanand]

In the next version of the Compose file format, we plan to make changes to the basic structure of the file (see #2421, #2478). We will preserve existing behaviour for users of the old file format.

This means we have a good opportunity to make other potentially-backwards-incompatible changes to the configuration format, as long as they only apply to files using the new version. If users are upgrading their files anyway, it's less hassle to make other required changes at that time.

Here are some proposed changes it'd be good to get in:

• Make net and volumes_from's container/service support explicit
• Move logging configuration under logging key
• New build config section
• Image and build together - not itself backwards-incompatible, but the implied changes to override logic (image will no longer override build, and vice versa) will be.

[aanand]

Added #2458 to the list, because of the implied changes to override logic.

[simonvanderveldt]

@aanand I guess adding a key for every type of driver makes sense? So not only logging, but also network and volume?
If so, maybe we should aggregate then under a drivers key? So we get:

drivers:
  network:
    driver: foo
    options: bar
  volumes:
    driver: foo
    options: bar
  logging:
    driver: syslog
    options:
      syslog-address: "tcp://192.168.0.42:123"

Although volume drivers could be service/container specific...

[aanand]

Volume drivers are complicated: you can choose a driver per container, and you can also choose a driver per volume. I presume the per-container driver is used when auto-creating volumes that don't already exist, but I'm not certain.

I presume what you're suggesting here is the ability to configure global default drivers. That might be a nice feature, but I don't think there's any particular pressure to have it in place in the first version of the new config format.

[simonvanderveldt]

Volume drivers are complicated: you can choose a driver per container, and you can also choose a driver per volume. I presume the per-container driver is used when auto-creating volumes that don't already exist, but I'm not certain.

Agreed, they are a bit more complicated. The same goes for the network driver.
I think using the per-container driver for services defined in docker-compose.yml makes the most sense.

I presume what you're suggesting here is the ability to configure global default drivers. That might be a nice feature, but I don't think there's any particular pressure to have it in place in the first version of the new config format.

Actually I think I misunderstood #2503 to be for a global definition for the logging driver, but the logging key you suggested would be a child of a service defined in docker-compose.yml, correct?
In that case I agree with you that a global default for a driver would be nice to have, but not a necessity at all and adding it later probably won't have impact on the config format.

[jainvipin]

+1