14:03:02 #startmeeting Rally 14:03:03 Meeting started Mon Oct 31 14:03:02 2016 UTC and is due to finish in 60 minutes. The chair is andreykurilin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:07 The meeting name has been set to 'rally' 14:03:11 o/ 14:03:51 hi 14:03:57 hi 14:05:19 I did not have enough time to prepare my notes related to summit, so I'll present them at next meeting 14:05:39 for today we have one item from agenda 14:05:43 let's start from it 14:05:56 #topic [astudenov] Let's discuss how db api should save task results data in chunks 14:07:23 astidenov proposed a change - https://review.openstack.org/#/c/391421/ 14:07:35 it fixes an issue related to saving results 14:07:52 nice, astudenov here) 14:08:37 hi all 14:09:12 in case of multi-node rally deployment, such fix will not work, since it is done on db-layer while saving full results. But it fixes "current" issue with saving big results 14:09:33 astudenov: hi. I started intro of your work) 14:11:21 andreykurilin: ok, thanks 14:11:48 so here are several questions: on what stage should we apply "chunking" ? What size chunks should be? chunk per iteration or specific amount of data? should we merge current fix and return to this question when work on distributed runner will start? 14:12:10 amaretskiy: any ideas? 14:13:06 i think it is reasonable to have chunk size configurable and it shoudl keep 1 or more iterations results 14:13:35 i need to review the fix, no ideas about merging right now 14:13:43 also I see -w on this patch 14:14:29 amaretskiy: yeah, it is just a wip. It was created to discuss the idea) 14:14:37 PoC 14:14:47 i will take a look on it 14:14:48 I think what 1 chink == 1 iteration is reasonable 14:15:33 in case 1 c = 1i - should we have chunk term at all ? 14:15:46 I't small enouth to store data and big enoth to track results 14:16:17 why not? 14:16:34 yeah, 1c = 1i sounds reasonable, but it can be redundant in case of very simple scenarios(with one atomic action) 14:16:39 if 1c=1i then we have duplicated entity 14:16:48 @chunk@ it's a part of data 14:17:06 as well as iteration results :) 14:18:16 is it possible to set some limit on data& 14:18:18 ? 14:18:23 also we need to take into account that we planned to compress chunks 14:19:48 we are currently compressing results 14:20:00 btw, in case of 1c = 1i and rps runner(let it be 400rps), we can kill database 14:20:01 lol 14:20:08 this is the only choice because json has redundant size 14:20:47 chunk size should be as max as possible 14:20:49 imho 14:21:01 100 iterations :) 14:21:06 or more 14:21:08 so actually the question is to set limit on chunk size 14:21:28 1c=1i seems not right to me 14:21:42 the number of iterations is chunk can be easily changed, i guess 14:21:59 why not having it configurable? 14:22:15 even via python constant for first time 14:22:18 we will make it configurable, but we need to set default value:) 14:22:24 amaretsky: yes, I think it should be a config file field 14:22:26 100 14:22:31 42 :) 14:22:40 42 14:22:41 42 (+1) 14:22:44 +1 for 42 14:22:45 lol 14:22:54 so we have 42 + 1 +1 = 44 14:23:02 :-D 14:23:03 xD 14:23:11 i am currently using 1k 14:23:25 420 14:24:04 initial value is not critical, i think 14:24:09 it looks like we have first agreement 14:24:22 1k is not much better than 42 ) 14:24:30 1024 14:24:49 #agreement the size of chunks should be configurable 14:25:12 #vote for configurable and initial value >=42 14:25:23 let it be 1k 14:25:31 #agreed 14:25:37 #agreed 14:25:37 nice 14:25:47 so we closed one of several questions 14:26:01 #agreed 1k iterations per chunk 14:26:02 another one - on which stage should we save results to db? 14:27:00 together with preparation of report? 14:27:43 current solution can be merged only as a temporary fix for saving big results. 14:27:47 report is not related to saving data 14:28:38 astudenov: if we merge current fix, there is a possibility that your boss will be satisfied and will not allow to continue work on improments 14:28:39 lol 14:28:49 *improvements 14:28:56 i think the most efficient way is saving data in the very end of scenario run, however this requires having enough rom 14:29:42 if some issues expected then lets save chunks as soon as we hav ethem 14:30:05 so result consumer should save results by chunks too 14:30:28 saving chunks asap can led to rally performance degradation due to jsonschema validation of data 14:30:58 but yeah, it would be nice to save them asap 14:32:02 chunk size should as big as possible to reduce number of validation calls 14:32:23 or validation on smaller parts can affect performance in less way 14:32:25 hm.. 14:32:33 we should check it:) 14:32:43 *validation of smaller 14:33:23 how about pure-python validation (fast) 14:33:57 as far as i know we dont use jsonschema for validating results? https://github.com/openstack/rally/blob/master/rally/task/runner.py#L241-L301 14:34:34 oh... I forgot that we already abandoned jsonschema for task results 14:35:18 ok, so I'm ok to save chunks as soon as we have them 14:35:28 and it should not be hard to implement 14:38:29 do we have an agreement? 14:39:41 amaretskiy astarove astudenov ^ 14:41:14 I agree that we should save chunk as soon as we have 1k iterations in results consumer 14:41:45 ok 14:41:52 looks like we have one more agreement 14:41:59 nice) 14:42:12 ok, anything else to discuss on current topic? 14:42:59 nothing from me 14:43:06 me too 14:43:10 ok 14:43:14 no 14:43:22 #topic Free discussion 14:43:57 I found a perfect Irish Pub... Is it a good topic for discussion?)) 14:45:21 :) 14:46:00 ok, if noone have topics to discuss, let's finish our meeting and I'll go there 14:46:04 it's good topic for selfy 14:46:14 ))) 14:46:33 thanks guys for participation 14:46:35 see you 14:46:38 #endmeeting