You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently any scenario that involves port creation cannot be used with Rally serial or constant runner when number or repetitions (times) is greater than 1 and/or number of parallel runners (concurrency) is greater than 1, unless we ignore the fact that multiple ports will be assigned the same IP address.
We could address it either by picking IP addresses at random (from the subnet range) or keeping global state to track which is the next unassigned yet IP address from the pool.
Not using Rally runner for repetitions prevents us from getting a timing profile from Rally, i.e. duration over iterations for each atomic task. Example of such profile can be seen here:
Another idea instead of random(), we could look at providing the scenario with a large subnet -- ie 192.168/16 -- then allowing the scenario to break this into /24s (or whatever the user passes).
This could be two additional fields we pass to the scenario -- allow the code to work as-is, but for people that want to take advantage of having concurrency,etc they pass these additional fields to get the benefit.
Good thought. When it was implemented, I didn't find a good way for allocating subnet to rally tasks and ip to runners, the subnets used by tasks were planned statically. For setup 20K port as background pressure as fast as possible, we run multiple rally tasks concurrently.
If you are working on performance test and require to use parallel runners, could you please implement this feature? We(eBay SDN team) are working on OVN overlay scalability test recently, we are happy to review and may benefit from this feature as well.
Currently any scenario that involves port creation cannot be used with Rally
serial
orconstant
runner when number or repetitions (times
) is greater than 1 and/or number of parallel runners (concurrency
) is greater than 1, unless we ignore the fact that multiple ports will be assigned the same IP address.We could address it either by picking IP addresses at random (from the subnet range) or keeping global state to track which is the next unassigned yet IP address from the pool.
Not using Rally runner for repetitions prevents us from getting a timing profile from Rally, i.e. duration over iterations for each atomic task. Example of such profile can be seen here:
https://people.redhat.com/jsitnick/ovn/create-and-bind-200-ports.html#/OvnNetwork.create_and_bind_ports/details
The text was updated successfully, but these errors were encountered: