Randomized project names exhausts docker's networks

[iamdanfox]

By default, DockerComposeRule uses a randomized project name. Using the V2 yml syntax, this causes a host machine to 'run out of networks'.

To fix this, we could switch the default round, so that project name is non-random by default. We've already had trouble with this before (https://github.com/palantir/docker-compose-rule/issues/40). Unfortunately, I can't remember why it was randomized in the first place (@crogers, @joelea)?

[joelea]

It caused issues with running tests in parallel.

[CRogers]

Yes, imo the default should be randomised project names or you get all kinds of problems with parallel tests.

docker-compose down removes networks. We should be calling that after running each test. Is this only something that affects people who choose to not destroy the composition (and so not call down) afterwards? If so, maybe we should warn them to give a fixed project name and about the networks problem.

On Thu, 1 Sep 2016, 12:35 joelea, [email protected] wrote:

It caused issues with running tests in parallel.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/palantir/docker-compose-rule/issues/99#issuecomment-244052785, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYR48BUTLOr3GNTZxEnx5xsJMP_aEVTks5qlriNgaJpZM4Jyjek .

[CRogers]

I just read #40. Are we still using ExternalResource? That has some weird semantics iirc, like not calling after if there was an exception, which could be exacerbating the problem.

[j-baker]

I think the ExternalResource

    private Statement statement(final Statement base) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                before();
                try {
                    base.evaluate();
                } finally {
                    after();
                }
            }
        };
    }

is safe for that, no?

[j-baker]

ah wait - the failure is if the error is in your before method; before should be in the try block. That's what could exacerbate the problem.

[iamdanfox]

@joelea can you elaborate on the "issues with running tests in parallel" you mention... do you mean running multiple instances of the same class at the same time? Or just multiple test classes that happen to be in the same folder?

[j-baker]

E.g. If you have two projects that both use the same docker compose file in different contexts, you can't run ./gradlew test --parallel. You can't e.g have a dev stack running and run the tests on a different cluster.

The bug here btw is that DCR can terminate having made no attempt to clean up its state. If DCR creates a network, it should delete it too, whether or not before() throws.

On Sep 30, 2016, at 20:58, iamdanfox <[email protected]mailto:[email protected]> wrote:

@joeleahttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_joelea&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=E6OQAKKrmd8TBW7uwGiANF_0mStlG0xAdQq4Omr-X-4&e= can you elaborate on the "issues with running tests in parallel" you mention... do you mean running multiple instances of the same class at the same time? Or just multiple test classes that happen to be in the same folder?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_docker-2Dcompose-2Drule_issues_99-23issuecomment-2D250837960&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=g85uuIvOgT7XEWfBPNm2Dv_Wj0cnp4nBlDUpwgkX75o&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AACmJW0WZZqOgzlVsgg9OplmkpNSnUZ8ks5qvWnUgaJpZM4Jyjek&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=wI31cg1BQtV4IgtyPtPMXBGSCeh0NiUnKUNPe-vqW34&e=.