This repository was archived by the owner on Jan 30, 2020. It is now read-only.
functional: reduce number of tests and total running time #1704
+26
−101
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As go test natively has an upper limit of 600sec in total for all tests, we should reduce total running time. So let's reduce number of units to be tested in the unit state tests, and reduce maximum block attempts for the metadata template test. This will fix the failure on semaphoreci, which has suddenly appeared since the dynamic metadata tests. This should make tests work for now. In the long run, it would be necessary to be able to tune the timeout.
dongsupark
force-pushed
the
dongsu/fix-hanging-fxtests
branch
from
d8cd200 to
0f84672
Compare
Functional test seems to have a limitation of 40 tests in total. When the number of tests becomes more than 40, no more cluster member can be created, so that test ends up with hanging mysteriously. To avoid that, let's reduce number of tests, mainly for dynamic metadata tests as well as unit action tests. It's just squashing similar tests.
dongsupark
pushed a commit
that referenced
this pull request
Nov 11, 2016
functional: reduce number of tests and total running time
dongsupark
pushed a commit
to endocode/fleet
that referenced
this pull request
Nov 15, 2016
As described in coreos#1704, functional test has a bug hitting an upper limit of ~40 tests in total. That's actually an issue of DBUS connections remaining opened even after nspawn containers got successfully terminated. That's why the number of unix sockets grows up to 256. $ netstat -nap | grep /var/run/dbus/system_bus_socket | wc -l 256 From that moment on, functional test hangs mysteriously. Sometimes users could see errors like "The maximum number of active connections for UID 0 has been reached." Its reason is that every DBUS connection was never closed. The more tests we add, the more stale DBUS connections we have. This bug has existed since the beginning. Fix it by adding conn.Close() after running systemd commands.
dongsupark
pushed a commit
to endocode/fleet
that referenced
this pull request
Nov 15, 2016
As described in coreos#1704, functional test has a bug hitting an upper limit of ~40 tests in total. That's actually an issue of DBUS connections remaining opened even after nspawn containers got successfully terminated. That's why the number of unix sockets grows up to 256. $ netstat -nap | grep /var/run/dbus/system_bus_socket | wc -l 256 From that moment on, functional test hangs mysteriously. Sometimes users could see errors like "The maximum number of active connections for UID 0 has been reached." Its reason is that every DBUS connection was never closed. The more tests we add, the more stale DBUS connections we have. This bug has existed since the beginning. Fix it by adding conn.Close() after running systemd commands.
dongsupark
pushed a commit
to endocode/fleet
that referenced
this pull request
Nov 15, 2016
As described in coreos#1704, functional test has a bug hitting an upper limit of ~40 tests in total. That's actually an issue of DBUS connections remaining opened even after nspawn containers got successfully terminated. That's why the number of unix sockets grows up to 256. $ netstat -nap | grep /var/run/dbus/system_bus_socket | wc -l 256 From that moment on, functional test hangs mysteriously. Sometimes users could see errors like "The maximum number of active connections for UID 0 has been reached." Its reason is that every DBUS connection was never closed. The more tests we add, the more stale DBUS connections we have. This bug has existed since the beginning. Fix it by adding conn.Close() after running systemd commands.
Contributor
|
can this be reverted after #1706? |
Author
|
@jonboulle Sure, I'll revert it. |
dongsupark
pushed a commit
to endocode/fleet
that referenced
this pull request
Nov 21, 2016
This reverts commit 0f84672, and reverts commit f81c3b2. a.k.a reverts coreos#1704
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Functional test seems to have a limitation of 40 tests in total. When the number of tests becomes more than 40, no more cluster member can be created, so that test ends up with hanging mysteriously. To avoid that, let's reduce number of tests, mainly for dynamic metadata tests as well as unit action tests. It's just squashing similar tests.
As go test natively has an upper limit of 600sec in total for all tests, we should reduce total running time. So let's reduce number of units to be tested in the unit state tests, and reduce maximum block attempts for the metadata template test. This will fix the failure on semaphoreci, which has suddenly appeared since the dynamic metadata tests. This should make tests work for now. In the long run, it would be necessary to be able to tune the timeout.