14:02:01 <andreykurilin_> #startmeeting Rally
14:02:02 <openstack> Meeting started Mon Sep 26 14:02:01 2016 UTC and is due to finish in 60 minutes.  The chair is andreykurilin_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:05 <openstack> The meeting name has been set to 'rally'
14:02:13 <andreykurilin_> hi !
14:02:19 <rvasilets> \o
14:02:21 <amaretskiy> hi
14:03:37 <andreykurilin_> let's start from the news
14:03:40 <andreykurilin_> #topic news
14:04:37 <andreykurilin_> Elections of Openstack PTLs for Ocata period are finished
14:04:42 <andreykurilin_> results are here - https://github.com/openstack/election/blob/master/doc/source/ocata_ptl_results.rst
14:04:52 <andreykurilin_> I'm new PTL of Rally :)
14:05:28 <amaretskiy> great!
14:05:49 <andreykurilin_> boris-42 thank you for your hard work. I expect that you will not forget about us and continue contribute to Rally project :)
14:05:55 <andreykurilin_> lol
14:06:55 <andreykurilin_> for those, who did not read my campaign promises - https://git.openstack.org/cgit/openstack/election/plain/candidates/ocata/Rally/andreykurilin.txt
14:08:38 <andreykurilin_> So we have a lot of "work in progress" tasks and we should try to finish them during next 6 monthes
14:08:46 <andreykurilin_> all of them are real
14:09:44 <andreykurilin_> another new - let's try to prepare to release Rally at the end of this week
14:10:18 <andreykurilin_> The question is Do we have any blockers?
14:10:57 <andreykurilin_> I see two tasks which should be finished before releasing new version
14:11:16 <andreykurilin_> 1) finish porting all scenarios to class-based style
14:11:21 <andreykurilin_> there is only one or two patches
14:12:14 <andreykurilin_> 2) new section in reports for hooks
14:12:58 <andreykurilin_> For the next release we should concentrate on merging all db stuff
14:13:07 <rvasilets> +1
14:13:09 <andreykurilin_> we have several patches which are ready to merge
14:13:27 <andreykurilin_> let's test it again and finish them
14:13:29 <amaretskiy> 2) new section in reports for hook  <-- work in progress, first results will be tomorrow
14:13:42 <andreykurilin_> amaretskiy: nice
14:14:18 <andreykurilin_> # neutron scenarios
14:14:25 <andreykurilin_> #topic neutron scenarios
14:14:47 <andreykurilin_> several weeks ago we found several bugs in neutron
14:15:06 <andreykurilin_> and it looks like neutron-team is ready to look at Rally more serious
14:15:38 <andreykurilin_> but we have several "shortcomings" there
14:15:56 <andreykurilin_> 1) bad usage of atomics
14:16:30 <andreykurilin_> boris-42 has a patch for that task
14:17:02 <andreykurilin_> 2) 3 scenarios should be ported to use "network" context
14:17:28 <andreykurilin_> We should try to find volunteer for that task
14:17:49 <andreykurilin_> Is there anybody here who ready to try it?
14:17:55 <rvasilets> for second one?
14:17:58 <andreykurilin_> yes
14:18:13 <andreykurilin_> for first one we have boris-42
14:18:14 <andreykurilin_> :)
14:18:48 <andreykurilin_> 3) nested atomics
14:19:04 <andreykurilin_> neutron scenarios have a lot of nested atomics
14:19:07 <rvasilets> This week we have a lot of chinese, need to invite them for contribution somehow
14:19:22 <andreykurilin_> and we should start supporting them
14:19:45 <rvasilets> new contributors - the are chinese
14:19:52 <rvasilets> *they
14:20:23 <andreykurilin_> ok
14:20:35 <andreykurilin_> let's try to ping them at our regular channel
14:20:55 <rvasilets> here are they https://review.openstack.org/#/q/owner:zhangzh.fnst%2540cn.fujitsu.com+status:open
14:21:01 <rvasilets> https://review.openstack.org/#/q/owner:maxj.fnst%2540cn.fujitsu.com+status:open
14:21:10 <rvasilets> https://review.openstack.org/#/q/owner:lei.lu%2540easystack.cn+status:open
14:21:16 <rvasilets> https://review.openstack.org/#/q/owner:hoangcx%2540vn.fujitsu.com+status:open
14:21:30 <rvasilets> They made a lot of small useless patches)
14:21:37 <rvasilets> into rally
14:21:41 <rvasilets> last week
14:22:07 <andreykurilin_> rvasilets: they are not useless!
14:22:20 <rvasilets> Ok
14:22:22 <andreykurilin_> please, be more tolerant
14:22:29 <rvasilets> Three of them from fujitsu
14:22:40 <rvasilets> I guess they are working under Rally
14:22:44 <andreykurilin_> it is nice!
14:23:11 <andreykurilin_> ok, it looks like I have no more topics to discuss
14:23:15 <rvasilets> Lets make their development more managed
14:23:19 <andreykurilin_> ))
14:23:33 <andreykurilin_> Any topics from you, guys?
14:23:54 <rvasilets> about RPC patch
14:24:09 <andreykurilin_> cool
14:24:20 <rvasilets> https://review.openstack.org/#/c/234195/
14:24:38 <andreykurilin_> assume RPC == RPS runner
14:24:49 <rvasilets> yeah
14:25:02 <andreykurilin_> #topic next level for RPS runner
14:25:19 <andreykurilin_> we should update this patch
14:25:25 <rvasilets> So what I need to do with it after rebase?
14:25:39 <andreykurilin_> I know a lot of folks who want this change
14:26:13 <rvasilets> I suggest to merge this one and if its needed to impore this feature in other patches
14:26:29 <rvasilets> *improve
14:28:10 <rvasilets> amaretskiy, andreykurilin_, how about that? Just rebase it
14:29:13 <amaretskiy> i don't like manual calculations for config - there is a comment from me left in this patch
14:29:40 <amaretskiy> this is not user-friendly
14:29:49 <andreykurilin_> rvasilets: I talk with several folks who want this change and they need one more option there. It should be easy to extend it - step for changing number of requests per second.
14:30:22 <amaretskiy> ok, i will look at this patch, meybe it's a time to move it forward
14:31:04 <andreykurilin_> also, maybe it is ok, that "max" can not be achieved(in case when "times" is too small) ?
14:32:35 <andreykurilin_> anyway, we should finish this task ... there are a lot of folks who want it
14:33:57 <rvasilets> if we can't reach max rps then we've faced with the question what to do with the rest rps that is not done yet. (in the patch raised an error for simplicity and was assumed to work on such stuff in futhure patches)
14:35:21 <rvasilets> Also it does for rps in range(min_rps, max_rps + 1, step) now. So what step you mean?
14:35:27 <rvasilets> andreykurilin_, ^
14:36:44 <andreykurilin_> rvasilets: in case of your patch, number of requests will be changed each second. for more "stable" results, we should repeat each RPS several seconds after changing it
14:37:29 <rvasilets> rps could be smaller then 1 as I member
14:38:22 <andreykurilin_> it is true
14:38:33 <andreykurilin_> but it doesn't metter
14:38:54 <andreykurilin_> I mean that we need to repeat each value of "rps" several times
14:39:07 <andreykurilin_> to achieve more "stable"  results
14:40:51 <rvasilets> I don't know how this change the code now. Will think. But the simplest way for me as a developer is to merge that patch and not to keep a bit unrelated this in feature patch
14:41:15 <andreykurilin_> rvasilets: it can be done via some generator like http://xsnippet.org/361999/
14:43:12 <rvasilets> I can't figure out it in a fly
14:43:35 <andreykurilin_> ok
14:44:13 <andreykurilin_> anything else to discuss?
14:44:17 <rvasilets> no
14:45:56 <amaretskiy> i have a small topic
14:46:26 <amaretskiy> this patch gives great improvements for API: https://review.openstack.org/#/c/369412/
14:46:36 <amaretskiy> this is a review request :) eom
14:47:00 <andreykurilin_> heh
14:47:50 <andreykurilin_> ok
14:47:53 <andreykurilin_> let's finish
14:47:55 <rvasilets> ok
14:48:02 <andreykurilin_> #endmeeting