Outputs Nodes that aren't compatible with v3.

[KittyFort]

Docker-autocompose (pulled today from git) creates version 3 compose files, but the output isn't exactly compatible with v3.

In the 2.x to 3.x migration documentation , we can see the following note:

Changed in compose-file version 3 The resources section replaces the older resource constraint options in Compose files prior to version 3 (cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit, mem_swappiness). Refer to Upgrading version 2.x to 3.x to learn about differences between version 2 and 3 of the compose-file format.

Autocompose currently outputs cpu_shares, cpuset, mem_limit, and memswap_limit which aren't valid in v3. The documentation link above shows a sample where you can reserve minimum CPU/Memory and a maximum limit - with CPU being allocated on a percentage basis, and memory on an absolute basis. The provided sample:

    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
        reservations:
          cpus: '0.25'
          memory: 20M

There's no longer any direct control over swap or CPU affinity because apparently compose v3 is designed for Docker's swarm mode and they won't allow any options in there that would provide direct hardware dependencies that might affect how things are assigned in the swarm (like pinning to a CPU when a particular host may not even have that many CPUs/cores).

Version 2.2 introduced the cpus setting, which exists in version 3, though moved to the deploy section. That might provide a good baseline for CPU utilization percentage.

Along with that, we should probably not output mem_limit or memswap_limit anyway when they're set to default values (e.g. memswap_limit: -1). Those are being output from containers without any explicit limit set.

The Networks output also seems invalid, but I haven't had time to dig into the why of that. At first glance, I'd say it's related to this issue comment. There's a good chance that if the network assigned is a bridge network ("Driver": "bridge") with the "com.docker.network.bridge.default_bridge": "true" option, we should just omit the network settings, as they'll be connected to the default bridge by default. I'll probably revisit that in another issue.

[Red5d]

Thanks! I've removed those cpu and memory fields in the latest commit

[Red5d]

...and I made another couple commits that removed the 'network' key when the container only has a bridge network.

[KittyFort]

Thanks for looking into this!