14:07:18 #startmeeting Rally 14:07:19 Meeting started Mon Mar 28 14:07:18 2016 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:07:22 The meeting name has been set to 'rally' 14:07:24 nice 14:07:27 andreykurilin: hm? 14:07:30 o/ 14:07:33 if the bot left or was disconnected at some point often the topic is not current 14:07:39 o? 14:07:45 okay so it works 14:07:48 anteaya: thanks 14:07:54 after the meeting if someone could ping someone in the -infra channel they can refresh the topic 14:07:58 boris-42: welcome 14:08:10 anteaya: got it, thanks:) 14:08:19 so 14:08:28 today we have an agenda 14:08:38 \o/ 14:08:40 finally :) 14:08:41 #topic I finally did something for rally 14:08:47 )) 14:08:57 so basically there is a bug in Rally code 14:08:58 boris-42: really? 14:09:16 we are not calculating properly load duration 14:09:23 no way) 14:09:25 I fixed that 14:10:04 so now load duration is calulated as a duration between first iteration start and biggest (started_at + duration) iteration 14:10:15 we need to fix the rest https://bugs.launchpad.net/rally/ 14:10:26 amaretskiy: ^ this should remove artefacts on reports 14:10:34 redixin: yep 14:10:47 boris-42: great fix 14:10:57 btw it's simple 14:11:20 so next topic is about pain that happen after that fix 14:11:36 #topic Rally / MGMT network / Pain 14:11:58 so guys seems like it's very hard to use rally when you don't have access to mgmt network 14:12:46 so there are 2 ways to address this 14:13:02 one is to finish faster deployment & verification refactoring 14:13:20 another is to finish work on rally as a service and run rally as a s regular service 14:13:42 i know one more way 14:13:49 run rally on separate nod and use raas - the best way imho 14:13:52 to create python-horizonclient 14:13:57 *node 14:14:04 redixin: that will work VERY VERY SLOW 14:14:16 that was a joke 14:14:26 redixin: btw people is working on that 14:14:30 =) 14:14:37 -_- 14:15:17 boris-42: I'll try to finish aas spec asap 14:16:21 andreykurilin: thanks 14:16:50 okay 14:17:16 #topic [amaretskiy] Balancing users: maybe do not support random choice at all, just switch to balancing silently? 14:17:41 amaretskiy: so I think that we neeed to support random choice 14:17:48 okay 14:17:54 amaretskiy: however I do agree that we can switch to round robin 14:17:58 amaretskiy: by default 14:18:10 this looks reasonable to me 14:18:27 balancing is what users expect 14:18:40 amaretskiy: so I do not think that it would be hard to support both 14:18:47 okay 14:18:52 amaretskiy: and add parameter in context for that 14:19:00 i was in doubt so I decided to add this topic 14:20:33 boris-42: lets discuss https://review.openstack.org/#/c/229896/ 14:20:50 andreykurilin: we already did, no? 14:21:03 it should not be blocker for distributed runner 14:21:12 amaretskiy: am I right? 14:21:30 not blocking 14:21:38 amaretskiy: andreykurilin so there is way to implemnet it 14:21:43 amaretskiy: andreykurilin that won't block 14:21:44 because each d-runner has its own index 14:21:59 so we can add shift by d-runner index 14:22:00 amaretskiy: andreykurilin so i think i remember the problem here 14:22:15 amaretskiy: andreykurilin we are not passing iteration index to context 14:22:22 no no 14:22:26 no titeration index 14:22:32 thi spatch uses RAMInt 14:22:42 so in case if we have d-runners 14:22:54 each of them will get next RAMInt value 14:23:01 same values 14:23:18 but they can add own index ro this value 14:23:22 for example 14:23:29 amaretskiy: nope 14:23:36 we started 3 distributed rally instances 14:23:42 amaretskiy: nope 14:23:45 ? 14:23:54 amaretskiy: each of runner will have it's unique index 14:24:15 first runner 1 + i * count_of_runners 14:24:25 second runner 2 + i * count_of_runners 14:24:27 and so on 14:25:21 so, for example, these runners starts their 1st iterations 14:25:35 amaretskiy: they will have unique iterations ids 14:26:01 not clear 14:26:13 what is not clear? 14:26:25 let's assume 3 runenrs 14:26:42 1 4 7 10 is for first runner 14:26:50 2 5 8 11 is for second runner 14:26:59 3 6 9 12 is for thrid runner 14:27:09 each of runners has unique ids of iterations 14:27:15 yes 14:27:27 so what is missing in that patch 14:27:33 is that we are not passing scenario id 14:27:42 no 14:27:49 as far as I remember yes 14:28:03 all these runners knows about tenants and users 14:28:13 they must balance them 14:28:22 amaretskiy: it's not runners work 14:28:27 amaretskiy: it's done in context method 14:28:37 amaretskiy: wich don't accept ID of iteration and it should accept 14:29:21 i do not see any problems with this patch 14:29:29 related to d-runners 14:29:55 amaretskiy: ITERATION_COUNTER = rutils.RAMInt() 14:29:59 amaretskiy: ^ this doens't work 14:30:25 amaretskiy: and to make it work properly you need to pass ITERATION ID to CONTEXT 14:30:37 hmmm, yes 14:30:39 amaretskiy: not to generate 14:30:43 amaretskiy: in each context 14:31:17 it's very easy to fix 14:31:18 passing iteration number will even work faster 14:31:20 andreykurilin: amaretskiy ^ 14:32:52 so that is only blocker 14:32:56 if somebody can do that 14:32:58 that will be nice 14:33:41 I believe vponomaryov will finish this patch 14:33:49 I will help him 14:33:49 amaretskiy: he was waiting for me 14:33:55 amaretskiy: to finish that part 14:34:05 amaretskiy: so I can finish that part 14:34:08 I will try today 14:34:12 with passing id 14:34:22 cool 14:37:33 any other topic? 14:37:44 nothing from me 14:38:02 nothing from me 14:38:57 boris-42: one more 14:39:00 from agenda 14:39:02 andreykurilin: ? 14:39:32 it is not saved:( 14:39:33 ok 14:40:01 topic: too many commands to display task results 14:40:29 #topic too many commands to display task results 14:40:32 soo 14:40:35 not too many 14:40:37 task report 14:40:40 task results 14:40:46 and task export in future 14:41:33 task detailed 14:41:34 :) 14:41:56 so actually we should remove task results in favor of task export 14:42:10 and task detailed should be task report with specific key 14:42:22 maybe it is better to remove `task detailed`? 14:43:00 and use `task results`, `task results --detailed`, `task results --json` ? 14:43:25 results and report differs 14:43:33 andreykurilin: so task detailed seems more like report 14:43:47 andreykurilin: so I would keep 2 commands task report (instead of task detailed) 14:43:49 "rally task detailed" can be merged into "rally task report" 14:43:53 and task export instead of task results 14:44:02 sounds reasonable 14:45:11 ok, let's deprecate `task detailed` in favor of task report 14:45:30 and `task results` in favor of `task export` 14:45:48 lets reduce number of commands:) 14:45:51 andreykurilin: however we will need to keep it depracted forever 14:45:51 =) 14:45:56 why? 14:46:06 andreykurilin: a lot of people is using it 14:46:19 boris-42: deprecated warning will fix it 14:47:40 boris-42: I raised this topic, because I found attempt to introduce one more command to display results... 14:47:50 andreykurilin: export? 14:47:55 error 14:48:00 or errors 14:48:04 andreykurilin: oh that is very bad UI 14:48:33 and there is no real objective against this command, because we already have separate command for different types of displaying results 14:48:47 *separate commands 14:49:29 yep we really should not add more commands 14:51:57 ok, it looks like we don't have more topics to discuss 14:52:03 #endmeeting