add telemetrygen public package #197
Conversation
| err := binary.Read(cryptorand.Reader, binary.LittleEndian, &rngseed) | ||
| if err != nil { | ||
| return fmt.Errorf("failed to generate seed for math/rand: %w", err) | ||
| } |
There was a problem hiding this comment.
question: in recent go versions the math/rand is already seeded with a random number, can we remove this and maybe use rand/v2 ?
There was a problem hiding this comment.
I extracted this code from APM Server systemtest/apmsoak. There is a comment there about this seed:
Create a Rand with the same seed for each agent, so we randomise their IDs consistently.
My understanding is that we want to use the same seed across all agents, so we could move to rand/v2 but we would still want to init a shared seed for all the agents. What do you think? I'm not 100% sure my understanding is still valid as that apmsoak package was quite old.
There was a problem hiding this comment.
I have a broader question with regards to this change.
From my understanding initially the apm-perf exposed a similar package in the past, but we intentionally decided to move away from this in #15 and replace it with cmd binaries only.
With this new change from @endorama we will reintroduce shared library back. Which I personally think is fine. However I want to get some clarity first if we should oscillate back and forth on this repo design.
|
@1pkg I had a similar doubt, but this PR does not move the same package that was made private public, but adds a new small package exposing the functionality. In this way the logic is still in the private package and we expose a very small API for accessing that functionality. Using the binary in the functionaltests would make everything more (and unnecessary in my opinion) complicated without providing any benefit. |
Create a public
telemetrygenpackage that can be reused outside of this module.Up to this point we only leveraged CLI commands available in this module directly from the CLI.
I wanted to use load generation for elastic/apm-server#14100, but the old
loadgenpackage that was imported in this module has been made private (I wasn't able to pinpoint why but I would expect for lack necessity).Introducing a public package to act as a shallow layer on top of the internals of this module would allow re-using the logic directly in Go.