Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: introduce a broadcast helper #2851

Closed
wants to merge 3 commits into from

Conversation

jbergstroem
Copy link
Member

Introduce a helper - very similar to common.localhostIPv4 that allows test runner to override a broadcast address. This is required in certain scenarios - like FreeBSD jails - since networking acts a bit different.

Refs: #2472

(I've enabled BROADCAST=$foo on both FreeBSD bots)

/R=@Trott, ?

@mscdex mscdex added the test Issues and PRs related to the tests. label Sep 14, 2015

return broadcastIPv4;
}
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing semicolon

Object.defineProperty(exports, 'broadcastIPv4', {

get: function() {
if (broadcastIPv4 !== null) return broadcastIPv4;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is it declared?

@jbergstroem
Copy link
Member Author

fixed some linting issues and a missing variable declaration.

Introduce a helper - very similar to `common.localhostIPv4` that allows test
runner to override a broadcast address. This is required in certain
scenarios - like FreeBSD jails - since networking acts a bit different.

Refs: nodejs#2472
@@ -107,6 +108,27 @@ Object.defineProperty(exports, 'localhostIPv4', {
}
});

Object.defineProperty(exports, 'broadcastIPv4', {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: rm blank line for consistency with the other similar blocks.

@Trott
Copy link
Member

Trott commented Sep 14, 2015

Nit: There's enough repeated code between the getters for broadcastIPv4 and localhostIPv4 that they should probably both call the same function just passing in an argument telling the function what environment variable to retrieve. (On the other hand, that can be refactored later.)

@jbergstroem
Copy link
Member Author

Should be good enough for ci now: https://ci.nodejs.org/job/node-test-pull-request/292/

@Trott
Copy link
Member

Trott commented Sep 14, 2015

LGTM if CI is happy

@jbergstroem
Copy link
Member Author

Lets get the refactor in while at it.

@Trott
Copy link
Member

Trott commented Sep 14, 2015

This doesn't seem to solve the problem with test-dgram-broadcast-multi-process.js on the 32-bit FreeBSD on the CI. Any ideas? https://ci.nodejs.org/job/node-test-commit-other/629/nodes=freebsd101-32/console https://ci.nodejs.org/job/node-test-commit-other/631/nodes=freebsd101-32/console

@jbergstroem
Copy link
Member Author

@Trott I emailed the servers admins a while ago; looks like the broadcast address is set incorrectly.

@Trott
Copy link
Member

Trott commented Sep 14, 2015

It does seem to fix it for FreeBSD 64-bit, so that's good!

@Trott
Copy link
Member

Trott commented Sep 14, 2015

And on 32-bit, although it doesn't make the test pass, it is an improvement. Without this change, test output was:

#[PARENT] sent 'First message to send' to 255.255.255.255:12346
#[PARENT] sent 'Second message to send' to 255.255.255.255:12346
#[PARENT] sent 'Third message to send' to 255.255.255.255:12346
#[PARENT] sent 'Fourth message to send' to 255.255.255.255:12346
#[PARENT] sendSocket closed
#[PARENT] Responses were not received within 5000 ms.
#[PARENT] Fail

With this change:

#[PARENT] sent 'First message to send' to 172.16.31.3:12346
#[CHILD] 93497 received 'First message to send' from {"address":"10.20.10.11","family":"IPv4","port":12346,"size":21}
#[PARENT] sent 'Second message to send' to 172.16.31.3:12346
#[CHILD] 93497 received 'Second message to send' from {"address":"10.20.10.11","family":"IPv4","port":12346,"size":22}
#[PARENT] sent 'Third message to send' to 172.16.31.3:12346
#[CHILD] 93497 received 'Third message to send' from {"address":"10.20.10.11","family":"IPv4","port":12346,"size":21}
#[PARENT] sent 'Fourth message to send' to 172.16.31.3:12346
#[CHILD] 93497 received 'Fourth message to send' from {"address":"10.20.10.11","family":"IPv4","port":12346,"size":22}
#[PARENT] sendSocket closed
#[PARENT] 93497 received 4 messages total.
#[PARENT] Responses were not received within 5000 ms.
#[PARENT] Fail

That's several steps in the right direction.

@jbergstroem
Copy link
Member Author

@Trott refactor lgtm as well?

@Trott
Copy link
Member

Trott commented Sep 14, 2015

@jbergstroem Yes, LGTM with the refactor.

@thefourtheye
Copy link
Contributor

I prefer writing the function after the variable declaration but I am okay with landing as it is. LGTM

@jbergstroem
Copy link
Member Author

I'll see if there's anything we can do in the host machine about broadcast before merging this so we actually "fix" the issue. Otherwise we might have to work around it in our CI.

@jbergstroem
Copy link
Member Author

Host rebooted, should've fixed the broadcast. I think we have a winner: https://ci.nodejs.org/job/node-test-pull-request/300/

@thefourtheye I'll move the function below.

@Trott can you confirm that it closes #2472 ?

@Trott
Copy link
Member

Trott commented Sep 14, 2015

https://ci.nodejs.org/job/node-test-commit-other/647/

It's actually worse now. Now both 64-bit and 32-bit FreeBSD are failing and the test-dgram-multicast-multi-process.js is failing on them as well as test-dgram-broadcast-multi-process.js.

On the upside, they are getting a specific broadcast address that isn't 255.255.255.255.

@jbergstroem
Copy link
Member Author

That's unfortunate. This PR should be pretty much ok to land since it at least gives us control. I'll avoid adding "fixed" then.

@Trott
Copy link
Member

Trott commented Sep 15, 2015

Yeah, actually, even though the tests failed, they're failing further along than before, so it's progress!

@Trott
Copy link
Member

Trott commented Sep 15, 2015

LGTM

@jbergstroem
Copy link
Member Author

Just wanted to update. We're still stuck with figuring out why broadcasting from jails aren't working as intended. This PR will work just fine but the test will still fail [for other reasons]. Not sure we should merge this just yet since it might be avoided by finding another solution in CI-land.

@jbergstroem
Copy link
Member Author

Thinking we might skip this -- ref nodejs/build#228.

@jasnell
Copy link
Member

jasnell commented Nov 14, 2015

@jbergstroem ... where are we at on this?

@jbergstroem
Copy link
Member Author

We still have the issue but are migrating away from jails in ci. I'm inclined to close and reopen if some other freebsd user can help debug (I didn't have access to host).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants