Support for multiple compose configs

[clangaxon]

Trying to upgrade from the old 5.3 pre-fork version to 1.1.0, we're running into the inability to have multiple docker-compose resources on a single box. In the old version, we hacked around --remove-orphans with options = ['-f', 'second.yml']. In this version, options is now a string and a string with a space doesn't seem to work:

Error: Execution of '/usr/local/bin/docker-compose -f /etc/docker/first.yml -f /etc/docker/second.yml up -d --remove-orphans' returned 1: .IOError: [Errno 2] No such file or directory: u'./ /etc/docker/first.yml'

27240 execve("/usr/local/bin/docker-compose-1.9.0", ["/usr/local/bin/docker-compose", "-f", "/etc/docker/first.yml", "-f /etc/docker/second.yml", "up", "-d", "--remove-orphans"], [/* 27 vars */] <unfinished ...>

Are we missing something? :)

Thanks.

[scotty-c]

@clangaxon because of the new version of stdlib this module uses we have to declare inputs as types ie strings, arrays etc. What is the use case to have multiple compose files on a single compute resource?

[clangaxon]

I had the same question, but I inherited this code. :)

The two configs are generated separately, and if each uses a separate docker-compose resource, the --remove-orphans wipes out the first one to run.

If this is a bizarre use case, we can come up with a work around, but it seemed like a useful feature.

Thanks!

[clangaxon]

We worked around this by rearranging the configs into separate directories so that docker-compose would pull a different project name. Support for -P might be a better way to support this?

Thanks.

[scotty-c]

@clangaxon Do you have an example docker-compose command (with the -P) that I can look at?
If it makes sense to add as a feature we can look at that.

[clangaxon]

I don't have an actual example since that's now how we solved it - we couldn't pass -p in 'options' because of the same string vs. array limitation. :)

In our case, we had e.g.:

/etc/docker/compose/first.yml
/etc/docker/compose/second.yml

docker-compose considered both to be in a project named 'compose' because of the directory name, and --remove-orphans wiped out the first container when the second resource executed.

It looks like -p allows explicitly setting the project name, so two resource definitions could co-exist in the same directory.

[jacobmw]

We are trying to use two compose files in order to have the 2nd compose file be an override for the first.
https://docs.docker.com/compose/reference/overview/#use--f-to-specify-name-and-path-of-one-or-more-compose-files
Our main compose file is provided by a 3rd party which we would like to leave unmodified to make updates easier, and then use our maintained compose file for the overrides.

[MWilsonPuppet]

This issue has been resolved in #332 .