-
Notifications
You must be signed in to change notification settings - Fork 154
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
[Feature Request] Allow disabling of execution segments when parallelism > 1 #90
Comments
Hi @jdheyburn, thanks for opening the issue and PR! I'm afraid I don't fully understand the problem here at the moment 😞 Looking at your PR, it looks to me like you expect to have N runners, each with 100% of the test load -- is that correct? If so, from operator's viewpoint that is 1 test run, not N. The same can be achieved with Could you please clarify a bit more? |
So I'm moving my k6 workloads from EC2 to k8s. For me to be able to get a production equivalent load of traffic against my target (Redis) when using EC2 instances, I had to split the work across multiple instances with k6 on them (I have some helper scripts that allow me to do this). I was not able to get 1 k6 instance to replicate the load we had seen in production. It is this workload which I am trying to get to run in the same manner on k8s, so when you say..
You are correct. My I hope that makes sense 🙂 |
@jdheyburn sorry for the delay! Thanks, I think I started to understand your use case 😅 However, one more thing: do you have plans to switch to distributed execution with operator? TBH, right now it sounds to me as a problem of migration, not the end goal. Also, a small detour about data. There is an ongoing related work here: Once this work is done, I think it might help with the data splitting problem. (Also, in case you have related input from your use case or otherwise, please consider sharing in those issues!) |
@yorugac No worries!
I do yes, but I am not sure when this would be. Currently I'm doing my tests off of my own docker image built from the attached PR, and I thought the extra config may be useful for some other people. The operator should have sensible defaults as it does, but it would be useful to make it flexible for others who are not following the defaults - sensibly 😄 Thanks for sharing the data splitting problem. I'm not entirely sure it can be applied to my testing but it'll give me something to think about. |
Hi @jdheyburn!
I personally consider your use case to be an issue primary of migration that we could definitely support better but there is more than one way to add support for migrations and no clarity yet on which is the best. Some additional input from community would definitely be very beneficial. That said, please leave this issue open: k6 team would appreciate it greatly if other users of k6-operator were to add their inputs here or simply add a vote with 👍 / 👎 Thank you for your initiative and effort and I hope the response will not discourage you 🙂 |
Not a problem at all, I'll work off my fork until I can get my test script to work with this parameter. Thanks for taking the time to discuss it 😃 |
Great operator, thanks for making it!
I would like some fine-grain control on the runners that are created. I noticed that when parallelism is > 1, the number of VUs is shared across all the workers. My number of VUs is somewhat dynamic, and I currently have runners quitting prematurely because there is no work to do.
It would be great if I could prevent this from happening.
The text was updated successfully, but these errors were encountered: