14:01:32 <boris-42> #startmeeting Rally
14:01:33 <openstack> Meeting started Mon Nov  9 14:01:32 2015 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:36 <openstack> The meeting name has been set to 'rally'
14:01:39 <boris-42> ping2everybody
14:01:58 <cjmarti2> hi
14:02:03 <boris-42> cjmarti2: hi
14:02:09 <boris-42> ping rvasilets
14:02:13 <ikhudoshyn> o/
14:02:16 <temujin_> hi
14:02:35 <rvasilets> o/
14:02:53 <e0ne> hi
14:03:05 <amaretskiy> hi
14:04:57 <boris-42> okay let's start
14:05:08 <boris-42> Meetings agenda is here: https://wiki.openstack.org/wiki/Meetings/Rally
14:05:16 <boris-42> seems like we have only one topic there
14:05:30 <yfried> hi
14:05:39 <boris-42> #topic [cjmarti] Blueprint discussion. Add the hability to re-run the tempest tests that failed in the last test execution.  https://blueprints.launchpad.net/rally/+spec/re-run-failed-tempest-tests
14:06:08 <boris-42> cjmarti2: you are welcome
14:07:03 <cjmarti2> ok, basically I noticed test repository (testr) has this option already but when running rally verify start you cannot use it so the idea is to add this option
14:07:51 <boris-42> cjmarti2: like add extra argument to "rally verify start "?
14:08:26 <cjmarti2> yes... it would be rally verify start --failing
14:08:38 <boris-42> cjmarti2: yep just finish reading BP
14:08:43 <cjmarti2> which will rerun failed test cases from previous execution
14:08:46 <boris-42> cjmarti2: so seems like not super hard task
14:08:53 <boris-42> cjmarti2: and seemslike quite useful
14:10:01 <cjmarti2> :D cool, I'm on it, I'll update the whiteboard
14:10:39 <boris-42> сcjmarti2 so I believe you can propose the patch and we will merge it=)
14:10:55 <yfried> boris-42: cjmarti2: I've said long ago that we need to integrate testr python module instead of bash execution
14:10:59 <rvasilets> rally verify start --failing => rally verify start --failed
14:11:04 <rvasilets> no&)
14:11:21 <ikhudoshyn> rvasilets: +1
14:13:12 <ikhudoshyn> cjmarti2: just curious, will we re-verify the very latest 'verify' or the latest for the current deployment?
14:13:45 <boris-42> ikhudoshyn: so we should dot the latest for the current deployment
14:14:02 <ikhudoshyn> boris-42: sounds reasonable
14:14:47 <ikhudoshyn> move on?
14:15:02 <boris-42> ikhudoshyn: yep
14:15:19 <boris-42> #topic [ikhudoshyn] Distributed load generation spec
14:15:21 <boris-42> #link  https://review.openstack.org/#/c/236979/
14:15:49 <ikhudoshyn> I've just addressed all points that were available by now
14:15:53 <boris-42> ikhudoshyn: do you have some news related to this stuff?
14:16:47 <ikhudoshyn> we've merged one patch (about 'merging lists') -- auxiliary for distributed runner, another one is in the pipeline
14:17:02 <ikhudoshyn> now I'm working on RunnerAgent code
14:17:05 <boris-42> ikhudoshyn: so the one question
14:17:29 <ikhudoshyn> yes?
14:17:30 <boris-42> ikhudoshyn: is it possible to have always TaskEngine -> RunnerAgent
14:17:49 <boris-42> ikhudoshyn: or we need to have 2 different RunnerAgents ?
14:18:42 <ikhudoshyn> well I thought that DistributedRunner will provire the same interface as RunnerAgent
14:19:08 <ikhudoshyn> so in the case of only one node, yes, it is TaskEngine->RunnerAgent
14:19:19 <ikhudoshyn> did I answer yr question?
14:19:39 <boris-42> ikhudoshyn: so that's a bit nasty architecture..
14:19:56 <ikhudoshyn> y?
14:20:00 <boris-42> ikhudoshyn: yes
14:20:11 <boris-42> ikhudoshyn: we will need to have in TaskEngine if condtion
14:20:26 <boris-42> ikhudoshyn: if distributed: do_one_agent() else do_antoher_agent()
14:20:36 <ikhudoshyn> not sure..
14:21:03 <ikhudoshyn> a think we should always store chunks of TaskResult in DB
14:21:22 <ikhudoshyn> if so, somebody would gather individual TRs into chunks
14:21:23 <boris-42> ikhudoshyn: how that is related to what I have just said?
14:21:33 <ikhudoshyn> that's what RunnerAgentDoes
14:22:00 <boris-42> ikhudoshyn: RunnerAgent should just provide list of chunks to engine (no?)
14:22:03 <ikhudoshyn> or we should teach TaskEngine to do it
14:22:14 <ikhudoshyn> boris-42: exactly
14:22:23 <boris-42> ikhudoshyn: I thought RunnerAgent will just provide chunks
14:22:27 <boris-42> ikhudoshyn: and slas
14:22:31 <ikhudoshyn> yes
14:23:02 <boris-42> ikhudoshyn: so it will be nice to think a bit more and try to avoid 2 runner agents
14:23:07 <ikhudoshyn> boris-42: oh, do you mean local/remote RunnerAgent separation?
14:23:10 <boris-42> ikhudoshyn: or merge runner agents and runners
14:23:28 <boris-42> ikhudoshyn: so runner will be able to rewrite how runner agents methods works
14:24:37 <ikhudoshyn> boris-42: that is Runner will return chunks instead individual results?
14:25:51 <ikhudoshyn> for me functionalities of RunnerAgent and Runner are rather orthogonal
14:26:17 <ikhudoshyn> Runners are plugins and RunnerAgent is not
14:26:17 <boris-42> ikhudoshyn: the problem here is that we are adding more levels
14:26:24 <ikhudoshyn> yes
14:26:30 <ikhudoshyn> that's true
14:26:43 <boris-42> ikhudoshyn: and this time RunnerAgent and RunnerDistributedAgent doesn't fit nicely if you think
14:27:09 <boris-42> ikhudoshyn: like in engine we will need to pick RunnerAgent or RunnerDistributedAgent and that will look like hack
14:27:43 <ikhudoshyn> boris-42: I see
14:27:45 <boris-42> e.g. person is specifing type "distributed" and "TaskEngine" not "RunnerAgent" in this case will pick the proper Runner class
14:28:13 <ikhudoshyn> looks like we should try adding this RunnerAgent functionality into base Runner class
14:28:32 <boris-42> ikhudoshyn: then you don't need to reinvent anything and add any other layers
14:28:45 <boris-42> ikhudoshyn: you will specify name of runner and it will be picked by engine
14:29:23 <boris-42> ikhudoshyn: I am not sure that this is ideal solution, but at least we can make some diagram that shows how architecture will look like in such case
14:30:45 <ikhudoshyn> boris-42: I'll think if we could make Runner 'smarter'  and if so, I'll update diargam
14:30:48 <ikhudoshyn> and spec
14:31:15 <boris-42> ikhudoshyn: thanks
14:31:43 <boris-42> anybody else does have any questions? no?
14:31:52 <mbonell_> Me
14:32:01 <ikhudoshyn> ur welcome)
14:32:49 <mbonell_> Just a friendly reminder of my patch is ready for code review :)
14:32:59 <rvasilets> )
14:33:46 <ikhudoshyn> mbonell_: sure, I just guess boris-42 was asking if there are questions on the topic)
14:33:52 <rvasilets> I think that Boris talked about questions related to distributed runner)
14:34:12 <mbonell_> Oops, sorry
14:34:24 <ikhudoshyn> mbonell_: but pls add link, so that we won't miss it
14:34:51 <boris-42> mbonell_: thanks for reminder we will try to review it
14:35:00 <boris-42> okay let's move to next topic
14:35:10 <boris-42> #topic [amaretskiy] Propose to increase minimal Jinja2 version in requirements
14:35:19 <boris-42> #link https://review.openstack.org/#/c/240556/
14:35:31 <mbonell_> Thanks, yes
14:35:41 <amaretskiy> jinja2 version in requirements has potential python3 support issue
14:36:05 <boris-42> amaretskiy: so curently rally doesn't work with python3?
14:36:07 <amaretskiy> requirements.txt - version >= 2.6
14:36:13 <mbonell_> https://review.openstack.org/240042
14:36:14 <amaretskiy> it works
14:36:17 <boris-42> amaretskiy: hm didn't mention before...
14:36:31 <amaretskiy> latest release - 2.8
14:36:42 <amaretskiy> so everyone i sprobably using 2.8
14:37:01 <amaretskiy> because jinja2 requirements loads latest release
14:37:09 <amaretskiy> py3 support starts from 2.7
14:37:22 <boris-42> amaretskiy: okay seems like reasonable change
14:37:30 <amaretskiy> so we have 2.8 release available (the best and works perfect)
14:37:34 <boris-42> amaretskiy: I hope dhellmann will merge that one-)
14:37:38 <amaretskiy> yes, change is reasonable
14:37:41 <amaretskiy> but
14:37:45 <amaretskiy> one question
14:38:05 <amaretskiy> maybe request version >=2.8 ?
14:38:22 <amaretskiy> set  latest release in requirements?
14:38:25 <amaretskiy> not 2.7 ?
14:38:39 <boris-42> amaretskiy: yep you can do that as well
14:38:53 <amaretskiy> okay, I will update patch in minutes
14:38:56 <amaretskiy> eom
14:39:52 <boris-42> ok
14:40:06 <boris-42> #topic [rvasilets] Do we have volunteers  to fix https://bugs.launchpad.net/rally/+bug/1420755 bug?
14:40:07 <openstack> Launchpad bug 1420755 in Rally "nova utils _boot_server function does not handle multiple networks" [Low,In progress]
14:40:35 <boris-42> rvasilets: I believe you should ping chenli tomorrow
14:40:36 <boris-42> aobut this
14:40:47 <rvasilets> Okey
14:41:19 <rvasilets> But if someone like this bug then you could manage it https://bugs.launchpad.net/rally/+bug/1420755
14:41:19 <openstack> Launchpad bug 1420755 in Rally "nova utils _boot_server function does not handle multiple networks" [Low,In progress]
14:42:10 <boris-42> rvasilets: by "you" you mean "me" ?
14:42:20 <rvasilets> no
14:42:25 <rvasilets> Community
14:42:42 <boris-42> rvasilets: then you should say not "you" but "one"
14:42:43 <boris-42> =)
14:42:54 <rvasilets> Ok
14:43:04 <boris-42> #topic Upcoming release
14:43:27 <boris-42> Okay team, I would like to finish work on the CTRL+C and we will cut the release
14:43:41 <boris-42> so I hope it will happen tomorrow
14:44:02 <boris-42> that's all from my side
14:44:13 <boris-42> #topic Open Discussion
14:44:24 <boris-42> does anybody has something to discuss?
14:44:44 <ikhudoshyn> nothing more from my side
14:45:26 <amaretskiy> one small note from me
14:45:49 <amaretskiy> please keep your eye on patch https://review.openstack.org/#/c/237632/
14:45:56 <amaretskiy> this spect will be updated soon
14:45:58 <amaretskiy> *spec
14:46:01 <amaretskiy> eom
14:46:12 <boris-42> amaretskiy: ok
14:46:21 <amaretskiy> also I've updated patch with jinja version
14:46:23 <boris-42> amaretskiy: what about testing that cleanup works well?
14:46:28 <amaretskiy> https://review.openstack.org/#/c/240556/
14:46:29 <boris-42> amaretskiy: are you workin gon that as well?
14:46:43 <amaretskiy> boris-42: this is in progress...
14:47:40 <amaretskiy> yes, I'm working on checking cleanup
14:47:52 <amaretskiy> there will be updates soon
14:47:54 <amaretskiy> eom
14:48:04 <boris-42> amaretskiy: ok great
14:48:11 <ikhudoshyn> a kind reminder https://review.openstack.org/#/c/238547/
14:48:56 <boris-42> ikhudoshyn: okay I'll do the reivew asap
14:49:10 <boris-42> okay let's end meeting
14:49:16 <boris-42> see you next week
14:49:19 <boris-42> #endmeeting