-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
chore(ci): Use variant Dockerfile for soak tests #10978
Conversation
Pulled out from #10942 since I'm not sure if we want the rest of that PR yet. This updates the soak tests to use the Dockerfile from whatever variant is being soaked rather than whatever revision the soak test happens to be ran from. This avoids issues with backwards incompatible changes to the Dockerfile causing the baseline to fail to build. Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
✔️ Deploy Preview for vector-project ready! 🔨 Explore the source changes: aa1094b 🔍 Inspect the deploy log: https://app.netlify.com/sites/vector-project/deploys/61eb494208bec1000787ca3a 😎 Browse the preview: https://deploy-preview-10978--vector-project.netlify.app |
For the soaks to work we need to vary as little as possible between compared SHAs, ideally just the Vector binary. All the incidental setup for soaks -- the terraform, container Dockerfiles etc -- should come from comparison so what we change in our PRs is represented as unchanged between baseline/comparison. If I understand this change correctly we're now varying both vector-the-binary and the soak Dockerfile in our experiments. This mostly won't matter -- the Dockerfile rarely changes -- but is a little counter to the goal of changing just the binary. This is maybe more important as the 'stride' of our soaks widen up to months or what not, instead of just a few hours as most are now. That said, I do understand now what happened in #10942 to inspire this change. That's tricky. It almost makes me wonder if the Dockerfile approach isn't busted and doing a cross-compilation then copying a release binary into a binary isn't the right move. As a part of #10447 my intention is to abandon containers entirely -- assuming when I do prototyping work the idea doesn't evaporate -- so, here soonish, this goofy issue goes away? |
Soak Test ResultsBaseline: 84b6663 ExplanationA soak test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine, quickly, if vector performance is changed and to what degree by a pull request. Test units below are bytes/second/CPU, except for "skewness". The further "skewness" is from 0.0 the more indication that vector lacks consistency in behavior, making predictions of fitness in the field challenging. The abbreviated table below, if present, lists those experiments that have experienced a statistically significant change in their throughput performance between baseline and comparision SHAs, with 90.0% confidence. Negative values mean that baseline is faster, positive comparison. Results that do not exhibit more than a ±8.87% change in mean throughput are discarded. The abbreviated table will be omitted if no statistically interesting changes are observed.
Fine details of change detection per experiment.
Fine details of each soak run.
|
👍 these are good points. I think a solution here might be to use the entire |
Yeah, I think that's the correct read to this. |
Closing since we moved away from using dockerfile for containerizing the whole soak test. |
Pulled out from #10942 since
I'm not sure if we want the rest of that PR yet.
This updates the soak tests to use the Dockerfile from whatever variant
is being soaked rather than whatever revision the soak test happens to
be ran from. This avoids issues with backwards incompatible changes to
the Dockerfile causing the baseline to fail to build.
Signed-off-by: Jesse Szwedko jesse@szwedko.me