geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrel Schneider <dschnei...@pivotal.io>
Subject Re: Nightly build failures caused by attempted use of default ports
Date Thu, 24 Aug 2017 14:27:34 GMT
I like the sound of #1:
1) use Docker for AcceptanceTest and IntegrationTest targets?

Does anyone know of a downside to running these tests in docker?

On Wed, Aug 23, 2017 at 12:06 PM, Jared Stewart <jstewart@pivotal.io> wrote:

> I think we just need to have AcceptanceTest (and possibly IntegrationTest)
> run inside Docker like DistributedTest already does.
>
> - Jared.
>
> > On Aug 23, 2017, at 11:32 AM, Anilkumar Gingade <agingade@pivotal.io>
> wrote:
> >
> >>> 1) use Docker for AcceptanceTest and IntegrationTest targets?
> > To be clear, the failing tests are only in Acceptance Test and
> Integration
> > Tests? And distributed tests are not seeing this issue as they are
> running
> > in docker now....If moving docker address this issue, my vote is for
> moving
> > docker; this makes all the tests to be run in similar environment.
> >
> >>> 2) not test default ports?
> > If the product supports default port; we need to have test for
> that...Most
> > of the early product evaluation is done with default port...
> >
> > -Anil.
> >
> >
> > On Wed, Aug 23, 2017 at 11:15 AM, Kirk Lund <klund@apache.org> wrote:
> >
> >> The following nightly build failures are tests that are testing default
> >> ports which are failing because the port is not available.
> >>
> >> Should we:
> >>
> >> 1) use Docker for AcceptanceTest and IntegrationTest targets?
> >>
> >> 2) not test default ports?
> >>
> >> 3) use a hacky System property to force Geode to think that some other
> port
> >> is the default port?
> >>
> >> 4) some other solution?
> >>
> >> testGet – org.apache.geode.rest.internal.web.RestServersJUnitTest
> >> a few seconds
> >> testServerStartedOnDefaultPort –
> >> org.apache.geode.rest.internal.web.RestServersJUnitTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedWhenConnected_server_dir –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedWhenConnected_server_pid –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedEvenWhenNotConnected_server_dir –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedEvenWhenNotConnected_server_pid –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> onlineStatusCommandShouldSucceedWhenConnected_server_name –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedWhenConnected_locator_dir –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> offlineStatusCommandShouldSucceedWhenConnected_locator_pid –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> onlineStatusCommandShouldSucceedWhenConnected_locator_name –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> onlineStatusCommandShouldSucceedWhenConnected_locator_port –
> >> org.apache.geode.management.internal.cli.shell.
> >> GfshExitCodeStatusCommandsTest
> >> a few seconds
> >> statusLocatorSucceedsWhenConnected –
> >> org.apache.geode.management.internal.cli.commands.
> >> StatusLocatorRealGfshTest
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message