Perl 6 - the future is here, just unevenly distributed

IRC log for #openstack-rally, 2014-12-05

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 openstackgerrit Pavel Boldin proposed stackforge/rally: Add the benchmark Blogbench for the Virtual Machines  https://review.openstack.org/97030
00:16 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure rally_verify_job  https://review.openstack.org/139262
00:19 openstackgerrit joined #openstack-rally
00:31 marcoemorais joined #openstack-rally
00:33 marcoemorais joined #openstack-rally
00:36 dmorita joined #openstack-rally
00:51 jjmb joined #openstack-rally
01:24 yaguang joined #openstack-rally
01:41 andreykurilin joined #openstack-rally
02:21 erkules_ joined #openstack-rally
02:56 fandi joined #openstack-rally
03:01 Poornima joined #openstack-rally
04:32 yaguang joined #openstack-rally
04:41 yaguang_ joined #openstack-rally
04:49 vaidy paboldin, ping
04:51 vaidy paboldin, i was going through the blueprint https://blueprints.launchpad.net/rally/+spec/vm-workload-driver
04:53 vaidy paboldin, i feel cbtool restricts us to set of tools
04:53 vaidy paboldin, why dont we come up with a generic platform in which all the tools like iperf netperf fsstress iozone iometer can be integrated
04:53 nkhare joined #openstack-rally
04:54 nkhare_ joined #openstack-rally
04:54 vaidy paboldin, because these tools are  very common tools which are used as part of benchmarking a vm
05:05 yaguang_ joined #openstack-rally
05:08 chandankumar joined #openstack-rally
05:24 chandankumar joined #openstack-rally
05:25 rvcehimanshu joined #openstack-rally
05:29 jlk How can I control in say a nova scenario how the concurrent runs get dispersed across tenants/users? I'm running into quota issues.
05:30 yaguang joined #openstack-rally
05:32 AlexF joined #openstack-rally
05:48 rdas joined #openstack-rally
05:56 Poornima joined #openstack-rally
06:07 rvcehimanshu joined #openstack-rally
06:32 rvcehimanshu joined #openstack-rally
06:49 openstackgerrit joined #openstack-rally
07:01 rvcehimanshu joined #openstack-rally
07:42 pboldin joined #openstack-rally
08:01 openstackgerrit Mikhail Dubov proposed stackforge/rally: Cover Rally with docstrings & Test this coverage  https://review.openstack.org/127192
08:08 pboldin joined #openstack-rally
08:09 nkhare joined #openstack-rally
08:34 rvcehimanshu joined #openstack-rally
08:37 openstackgerrit Mikhail Dubov proposed stackforge/rally: Cover Rally with docstrings & Test this coverage  https://review.openstack.org/127192
08:48 pboldin guys, i'm sorry for the code quality but i have not reviewed it yet myself
08:48 pboldin i'm mostly updating this because i want rally gates to pickup my test and it fails atm
08:48 oanufriev joined #openstack-rally
08:59 AlexF joined #openstack-rally
09:09 openstackgerrit Pavel Boldin proposed stackforge/rally: Add the base method for the benchmarking of VMs  https://review.openstack.org/98172
09:09 openstackgerrit Pavel Boldin proposed stackforge/rally: Add the benchmark Blogbench for the Virtual Machines  https://review.openstack.org/97030
09:09 openstackgerrit Pavel Boldin proposed stackforge/rally: Add the context benchmark_image  https://review.openstack.org/138466
09:12 pboldin I will address all the review comments today
09:17 stannie joined #openstack-rally
09:26 amaretskiy joined #openstack-rally
09:32 andreykurilin_ joined #openstack-rally
09:34 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure rally_verify_job  https://review.openstack.org/139262
09:54 andreykurilin_ joined #openstack-rally
10:09 chandankumar joined #openstack-rally
10:21 andreykurilin_ joined #openstack-rally
10:21 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure rally_verify_job  https://review.openstack.org/139262
10:21 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
10:29 cdent joined #openstack-rally
11:04 openstackgerrit Roman Vasilets proposed stackforge/rally: 100% coverage in functional tests  https://review.openstack.org/138134
11:16 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
11:23 vkmc joined #openstack-rally
11:30 openstackgerrit Andrey Kurilin proposed stackforge/rally: Add scenario for booting vm with security groups  https://review.openstack.org/129282
11:38 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
12:00 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
12:09 prmtl joined #openstack-rally
12:31 openstackgerrit Ravikumar Venkatesan proposed stackforge/rally: Adds trove python client to rally.osclients  https://review.openstack.org/139047
12:56 pboros joined #openstack-rally
13:26 mwagner_lap joined #openstack-rally
13:49 openstackgerrit Roman Vasilets proposed stackforge/rally: 100% coverage in functional tests  https://review.openstack.org/138134
13:50 openstackgerrit Roman Vasilets proposed stackforge/rally: 100% coverage in functional tests  https://review.openstack.org/138134
13:53 dpaterson joined #openstack-rally
13:55 vaidy paboldin, ping
14:00 cat2jackson joined #openstack-rally
14:02 paboldin vaidy: what are you interested in?
14:05 vaidy paboldin, as i mentined yesterday i was thinking to work on developing a generic platform to plugin any io generation tool
14:05 vaidy inside the vm
14:05 vaidy paboldin, cbtool already seems to be having set of tools
14:05 paboldin vaidy: i have started doing this: https://review.openstack.org/#/c/137414/ but for FIO as for now
14:06 paboldin vaidy: first step is to merge generic benchmarking context for VMs
14:07 rook joined #openstack-rally
14:07 vaidy paboldin, yes agree have you thought about the generic benchmarking context??
14:07 paboldin vaidy: oh, it seems that cbtool is not connected to openstack yet
14:07 paboldin vaidy: yeah, look at these: https://review.openstack.org/#/c/138466/
14:08 paboldin (and references therein)
14:09 paboldin vaidy: i have plan to finish it before monday
14:09 vaidy paboldin, ok
14:10 paboldin vaidy: then we would be able to start developing our required benchmarks
14:10 vaidy paboldin, cool this is exactly what i am trying to achieve
14:10 vaidy paboldin, please do let me know if you need any help in your task
14:11 paboldin vaidy: okay. i'm not sure of this yet
14:11 paboldin vaidy: here is a preliminary results: http://i.imgur.com/ncsHLt6.png for FIO
14:11 vaidy paboldin, interesting
14:12 vaidy paboldin, i am trying to integrate different tools like iozone, iometer, fsstress, iperf, netperf
14:12 paboldin vaidy: same here. let's do it together
14:12 paboldin vaidy: difference with iperf/netperf is that you need to establish a topology
14:13 vaidy paboldin, once the base is ready we can go ahead and implement with others
14:13 vaidy paboldin, it should be easy
14:13 vaidy paboldin, sure
14:13 vaidy paboldin, we will do it together
14:13 paboldin vaidy: yeah, but the thigns we need to think of right now is a generic framework for parsing the results and so on
14:14 paboldin vaidy: ok. add me on skype also: pavel.boldin (and mail is pboldin@mirantis.com)
14:14 vaidy paboldin, give me a min
14:40 openstackgerrit Wataru Takase proposed stackforge/rally: Add name pattern filter for resource cleanup  https://review.openstack.org/139643
15:01 openstackgerrit Anton Arefiev proposed stackforge/rally: Add cinder stress scenario: nested snapshots  https://review.openstack.org/139019
15:04 cdent joined #openstack-rally
15:20 andreykurilin_ joined #openstack-rally
15:31 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
15:33 openstackgerrit Andrey Kurilin proposed stackforge/rally: Add scenario for booting vm with security groups  https://review.openstack.org/129282
15:55 openstackgerrit Roman Vasilets proposed stackforge/rally: 100% coverage in functional tests  https://review.openstack.org/138134
16:56 jjmb joined #openstack-rally
17:14 openstackgerrit Roman Vasilets proposed stackforge/rally: 100% coverage in functional tests  https://review.openstack.org/138134
17:18 openstackgerrit Andrey Kurilin proposed stackforge/rally: WIP: configure gate-rally-dsvm-verify  https://review.openstack.org/139262
17:20 openstackgerrit Merged stackforge/rally: Added hacking rule for assertEqual(A in/not in B, True/False)  https://review.openstack.org/139022
17:55 leeantho joined #openstack-rally
17:57 boris-42 joined #openstack-rally
17:58 jlk So when using RPS, for something like boot and delete nova, is there a way to do both concurrency and rps? I want to do this test 100 times, with a concurrency up to 70, but I can't handle more than 70 instances at a time. Seems RPS is times == concurrency.
18:14 mwagner_lap joined #openstack-rally
18:15 boris-42 jlk: around?
18:15 jlk boris-42: yup
18:15 boris-42 jlk:  so actually I am in vacation=) but lemme try to help you=)
18:16 boris-42 jlk:  so what you are trying to do?
18:16 boris-42 jlk:  you would like to have 100 active instance at the end?
18:19 jlk I want to test boot, delete, I want to test it 100 times, and I want to have concurrency up to 70, and I want to limit it to no more than 5 submitted per second.
18:19 jlk boris-42: ^
18:20 boris-42 jlk:  so if you specify in RPS rps: 70
18:20 boris-42 jlk:  it will run 70 per second (in real life it can be more than 70 active threads)
18:21 boris-42 jlk: then you need to specify times (which means the total amount of executed scenarios)
18:21 jlk yeah, 70 per second is way too much. Breaks my cloud.  I'm getting good results with between 5 and 10 per second
18:21 boris-42 jlk:  yep seems like true lol*
18:22 rook joined #openstack-rally
18:23 boris-42 jlk:  so you need to put enough to "times"
18:24 boris-42 jlk:  if you are looking for running exactly amount of threads (then you should use constant runner)
18:24 jlk so what I see happening, is that in this test, times == concurrency
18:24 boris-42 jlk: nope
18:24 jlk so if I put 100 times, it'll try to launch 100 instances
18:24 jlk or at least it won't limit itself to no more than X instances runing at once
18:24 boris-42 jlk:  nope it doesn't mean times == concurrency
18:25 jlk I don't see a way to limit RPS to # of times concurrently running
18:25 boris-42 RPS is not about that*
18:25 boris-42 RPS - is how much to shot per second
18:25 boris-42 like 10 -> every six second start/delete new VM
18:25 jlk I understand. But there is no other way to throttle
18:25 boris-42 jlk:  so basically we need another runner or to improve rps runner
18:25 jlk if I do constant, and I want to test 100 builds, it's going to fire off up to concurrency level
18:26 jlk if I put 70 in concurrent, it'll try to do all at once, and I get near 50% failure :(
18:26 boris-42 jlk:  it depends on many things*
18:27 boris-42 jlk:  but what I think is that you need somehow to limit speed
18:27 boris-42 jlk: if cloud can't handle it*
18:27 boris-42 jlk:  do I understand properly that?
18:28 jlk boris-42: that sounds about right. Either a rps like throttle on concurrency, or a concurrency like throttle on PRS
18:28 boris-42 jlk:  so we can actually improve current RPS runner
18:28 boris-42 jlk:  to add such possilbiltiy
18:28 jlk okay
18:29 boris-42 jlk:  like "max_threads"
18:29 boris-42 jlk: or something better (that will slow down RPS runner)
18:30 boris-42 jlk:  wanna contribute to rally? )
18:32 jlk I can look into it.
18:35 jlk I have some capacity for upstream work, this could fall into it, but no guarantees
18:35 boris-42 jlk:  just try it we will help from our side
18:35 boris-42 jlk: to get it in
18:35 jlk yeah
18:51 openstackgerrit Merged stackforge/rally: Adds trove python client to rally.osclients  https://review.openstack.org/139047
18:51 openstackgerrit Merged stackforge/rally: Workflow documentation is now in infra-manual  https://review.openstack.org/139498
18:58 boris-42 jlk:  lol if we merge your patch you'll be 90's contributor to rally =)
18:58 boris-42 90th*
19:03 jlk boris-42: that's a good number actually.
19:33 jlk Argh, so much math :)
19:35 boris-42 jlk: ;)
19:49 marcoemorais joined #openstack-rally
20:00 jlk reading though this, I /think/ what I need is a global pool for the tasks. This pool would be created with a limit of max_threads. A thread would be running continually trying to put tasks into the pool. Each of the _worker_process threads will try to pull tasks from the pool, at their configured rate.
20:03 jlk the adder thread will block once it reaches max. The worker threads will attempt to pull from the pool. May block if the pool is empty though. hrm.
20:07 jlk wait, no.
20:08 jlk Need a global pool. Worker threads break up the task set and have a rps. Instead of executing the scenario directly, it submits to the global pool, which has a max concurrency. This feels right
20:36 marcoemorais joined #openstack-rally
20:37 marcoemorais joined #openstack-rally
20:51 jlk ah, need a global queue, not a global pool
21:18 marcoemorais joined #openstack-rally
21:42 jlk holy shit I think I got it to work.
21:49 jjmb joined #openstack-rally
22:01 marcoemorais joined #openstack-rally
22:01 marcoemorais joined #openstack-rally
22:02 marcoemorais joined #openstack-rally
22:45 penguinRaider joined #openstack-rally
22:52 andreykurilin_ joined #openstack-rally
23:21 boris-42 joined #openstack-rally
23:34 marcoemorais joined #openstack-rally
23:59 vkmc joined #openstack-rally

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary