Integration test for Docker and perf stats#2489
Conversation
iwankgb
force-pushed
the
perf_integration_tests
branch
4 times, most recently
from
8d0b455 to
1fc64df
Compare
iwankgb
force-pushed
the
perf_integration_tests
branch
from
9af4e46 to
478f27b
Compare
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
iwankgb
force-pushed
the
perf_integration_tests
branch
from
478f27b to
4dc7481
Compare
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
iwankgb
changed the title
|
@dashpole, you will find a proposal for extending integration tests in this PR. What changes is that integration tests are being run for "normal" build of cAdvisor (i.e. with no tags) and for a custom one (with |
| CADVISOR_ARGS="$CADVISOR_ARGS" /usr/local/bin/runner.sh build/integration.sh" | ||
| } | ||
|
|
||
| run_tests "-race" "sudo" |
There was a problem hiding this comment.
Is there a reason why we want to do perf tests separately? Are they expected to fail in some scenarios?
There was a problem hiding this comment.
Just read the comment above. I think this is a reasonable solution, although I think we should consider having a separate target. That way users who just want to run the "distro agnostic" tests can do so without having errors mixed in.
|
|
||
| assert.Nil(t, err) | ||
| assert.Len(t, info.Stats, 1) | ||
| assert.Greater(t, len(info.Stats[0].PerfStats), 0, "Length of info.Stats[0].PerfStats is not greater tahn zero") |
| assert.Greater(t, len(info.Stats[0].PerfStats), 0, "Length of info.Stats[0].PerfStats is not greater tahn zero") | ||
| for k, stat := range info.Stats[0].PerfStats { | ||
| //Everything beyond name is non-deterministic unfortunately. | ||
| assert.Contains(t, []string{"context-switches", "cpu-migrations-custom"}, stat.Name, "Wrong metric name for key %d: %#v", k, stat) |
There was a problem hiding this comment.
Are we guaranteed to have more than 0 of either of these events? Even that check can sometimes catch problems...
There was a problem hiding this comment.
In waitForContainerInfo() we wait for v1.ContainerInfo to be available. Perf stats are part of this structure and I would consider it a bug if they were not available.
|
cc @dims |
|
+1 to "perf tests separately" please! looks reasonable otherwise :) |
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
iwankgb
force-pushed
the
perf_integration_tests
branch
2 times, most recently
from
4cd5cf6 to
396c32a
Compare
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
Signed-off-by: Maciej "Iwan" Iwanowski <maciej.iwanowski@intel.com>
|
@dashpole @dims - is such approach acceptable? Changes are:
Eventually it would make sense to execute unit tests in Docker too, I think. There are some unit tests against libpfm4 part of code that can be executed without installing the library. What is you opinion? |
|
@iwankgb works for me! |
4 participants
Integration tests for Docker container and perf stats.