-
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
Introduce end-to-end performance test bed #8
Comments
@flands can you assign this to me? |
Thanks, @SergeyKanzhelev |
@bogdandrutu @SergeyKanzhelev I have the first version of the performance test bed implemented and running. The repo is here https://github.com/Omnition/opentelemetry-service-testbed and the execution results look like this https://github.com/Omnition/opentelemetry-service-testbed/blob/master/tests/results/TESTRESULTS.md We would like to contribute this to OpenTelemetry. The only question is if it possible for me and one more developer from Omnition to be assigned as Maintainers on this particular repo. We plan to continue to actively improve the test bed and want to make sure we will not be blocked during the active development phase (which can happen if someone else outside the company needs to approve the PRs). Do you think it is possible to do? |
@tigrannajaryan repos looks to be private. If those are generic enoguh - we should definitely pick those up. I assume you want a separate repository, not this one. Every repo is bootstrapped with a couple of maintainers. Ideally from different companies. So the standard process of becoming approver and maintainer can work. As we are in early stages we are expediting this process. So it is absolutely possible to make a repo and assign maintainers quickly. However, I'd suggest to get support from anybody from other company to have a "healthy" repository. |
@SergeyKanzhelev Sorry, I have just made it public if you want to have a look. |
@bogdandrutu @@songy23 any of you interested? |
Feel free to add me, or we can just reuse the code owners in this repo. |
Thanks @songy23 :-) @SergeyKanzhelev would it be enough to bootstrap the testbed with me, @pjanotti (also from Omnition) and @songy23 as maintainers? |
Absolutely. I see no problems with this. I can set everything up later tonight or in the morning tomorrow. |
Thanks @SergeyKanzhelev Let me know if there is anything that I can help with. You can either fork our repo and I will delete our copy or I can transfer ownership of our repo to open-telemetry Github org. Whichever you prefer. |
You can send PR here: https://github.com/open-telemetry/opentelemetry-service-testbed I will make you maintainers once PR will be approved in community repo. Just in case anybody have concerns |
@SergeyKanzhelev here is the PR: https://github.com/open-telemetry/opentelemetry-service-testbed/pull/2 |
QQ: Why this cannot live in the same repo with the service? |
@bogdandrutu It can. The only reason I wanted it to be separate is to be able to get maintainer rights, which I thought would be easier for this small subset of codebase. The reason I want to have maintainer rights is that we (at Omnition) are currently very actively investing into the testbed and adding end-to-end tests in order to improve our confidence in the Service and have automated track record of performance improvements we work on. I am not a maintainer on the Service repo, and it would make the development of the testbed much slower if I needed to wait for other maintainers to review and give approval. If you think it is possible for me apply and become a maintainer of the Service repo that would solve the problem. |
It will be great if eventually tests would include some unusual combinations of arguments like span with a lot of links and such. And those can be used by other repositories. At least this was my expectation for creating a separate repo =) If permissions is the only problem - we should fix it and ask maintainers to iterate faster |
I think from technical perspective it can work with either approach, in the same repo or separate. From organizational perspective it probably makes a little more sense to have the tests in the same repo since it is highly likely that the same people work the Service will also work on the test bed. My only concern is the ability to move at sufficient velocity. I have internal deadlines which will be impossible to achieve if the PR review turnaround is a few days (which is the typical time I have experienced so far). If we are not ready to move at a higher pace the alternate approach is for us to keep the testbed as an Omnition repo, iterate on it fast internally and then contribute the end result as a turnkey testbed. I am happy with either approach, just let me know how you would like to move forward. |
@bogdandrutu you are one of maintainers on service. Can you please decide on how to move forward here. |
We should stay with this repo. |
@tigrannajaryan when you are ready please move the code here when you feel ready. |
* Initial commit * Add CODEOWNERS file (#2) * Add CODEOWNERS file * Update CODEOWNERS * Moved from github.com/observatorium/opentelemetry-collector-builder (#3) Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * fixed panics (#6) Signed-off-by: Joe Elliott <number101010@gmail.com> * Replace master with main in CI and mergify files (#8) Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Bump to OpenTelemetry Collector 0.20.0 (#10) Closes #9 Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Explicitly enable Go modules in quickstart instructions (#13) * Update to collector v0.21.0 (#17) Fixes #16 Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Update to collector v0.22.0 (#19) * Download go modules before building (#20) Fixes #14 * Add version command (#25) Signed-off-by: Ashmita Bohara <ashmita.bohara152@gmail.com> * Pass errors from cobra Execute back to main for correct exit code (#28) * pass errors from cobra execute back to main * print the error * Update to collector v0.23.0 (#27) * Generate a warning if the builder and collector base version mismatch (#30) * Generate a warning if the builder and collector base version mismatch * Show current default version in the warning message * Update to OpenTelemetry Collector 0.24.0 * Don't use %w formatting with log.Fatal (#35) * Update to OpenTelemetry Collector 0.25.0 (#36) Signed-off-by: Serge Catudal <serge.catudal@gmail.com> * Update to 0.26.0 and update BuildInfo (#39) * Sync build and CI Go versions at latest 1.16 (#34) * Sync build and CI Go versions at latest 1.16 * Run go mod tidy * Set go binary to use in the compilation phase in tests Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> Co-authored-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Add option to generate go code only (no compile) (#40) * Issue#24 Add option to generate go code only (no compile) * Update cmd/root.go logging Suggested by @jpkkrohling Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de> * remove verbose help .. created by corba * suggestion by jpkrohling to keep generateandcompile * lint error: remove unused var * reword cmd option and add back help message for default Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de> * Don't reuse exec.Cmd (#42) * Update to OpenTelemetry Collector 0.27.0 (#43) * Add CI Badge (#47) * Update to Collector v0.28.0 (#49) * Update to Collector v0.28.0 Closes #48 Addresses the breaking API change in #3163, besides the usual version number changes. Signed-off-by: Fangyi Zhou <me@fangyi.io> * Use `go mod tidy` instead of `go mod download` It appears that this magically resolves the go.mod file issue. https://stackoverflow.com/questions/67203641/missing-go-sum-entry-for-module-providing-package-package-name Signed-off-by: Fangyi Zhou <me@fangyi.io> * Account for go mod download in go1.17 not updating go.sum (#50) * Update to collector v0.29.0 (#54) * Update replaces.builder.yaml * Update nocore.builder.yaml * Update config.go * Update README.md * Update main.go * Update to collector v0.30.0 (#57) * cmd: fix module flag default value to github.com/open-telemetry (#58) Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com> * Update to collector v0.31.0 (#60) * Update to v0.33.0 (#62) Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Add excludes support to generated go.mod (#63) Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> Co-authored-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Small cleanup for the builder files (#64) Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com> * Support building with Go 1.17 (#66) * Support building with Go 1.17 Fixes #65 Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Update workflows to use Go 1.17 Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Add gosec exceptions for exec.Command Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Update to OpenTelemetry core 0.34.0 (#68) Fixes #67 Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> * Upgrade to OpenTelemetry Collector 0.35.0 (#70) Signed-off-by: Fangyi Zhou <me@fangyi.io> * Upgrade to OpenTelemetry Collector 0.36.0 (#76) * Generate custom service code for Windows (#75) * update main to include windows service code * use main version from tag 0.35.0 * update main function * align with upstream v0.36.0 tag * dummy change to trigger build * Revert "dummy change to trigger build" This reverts commit 629d499461da2d2c240bf1e495b5fe0558e3547f. * Remove Core from Module type (#77) Fixes #15 Signed-off-by: yugo-horie <u5.horie@gmail.com> * release 0.37.0 (#78) * release 0.37.0 * update use of NewCommand * Move builder to subdirectory Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de> Co-authored-by: Bogdan Drutu <lazy@splunk.com> Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com> Co-authored-by: Joe Elliott <joe.elliott@grafana.com> Co-authored-by: Eric Yang <jiwen624@gmail.com> Co-authored-by: Brian Gibbins <eroteme@supernought.co.uk> Co-authored-by: Ashmita <ashmita.bohara152@gmail.com> Co-authored-by: Fangyi Zhou <me@fangyi.io> Co-authored-by: Shaun Creary <65406540+crearys@users.noreply.github.com> Co-authored-by: Patryk Małek <69143962+pmalek-sumo@users.noreply.github.com> Co-authored-by: Serge Catudal <serge.catudal@gmail.com> Co-authored-by: Aaron Stone <aaron@serendipity.cx> Co-authored-by: Patryk Małek <pmalek@sumologic.com> Co-authored-by: Aaron Stone <aaron.stone@udacity.com> Co-authored-by: Kelvin Lo <kello@live.ca> Co-authored-by: Himanshu <addyjeridiq@gmail.com> Co-authored-by: Y.Horie <u5.horie@gmail.com> Co-authored-by: Koichi Shiraishi <zchee.io@gmail.com> Co-authored-by: Anthony Mirabella <a9@aneurysm9.com> Co-authored-by: Cal Loomis <68860480+loomis-relativity@users.noreply.github.com> Co-authored-by: alrex <aboten@lightstep.com>
Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
To have clean consistent formatting
The goal is to a create a test best - controlled environment and tools for conducting performance tests for the OpenTelemetry Agent, including reproducible short-term benchmarks, long-running stability tests and maximum load stress tests.
The test bed must allow specifying a configuration of the test, the load that needs to be generated, and be able to run and produce machine and human readable results. It should be possible to run the test bed locally on a developer machine or on a cloud.
Here is a more detailed proposal:
https://docs.google.com/document/d/1omU06mBYGY0slT1yojttn9BCyp18pHaRjkkYZrY8H4Q/edit#heading=h.9pln30mjg237
The text was updated successfully, but these errors were encountered: