14:03:08 #startmeeting Rally 14:03:09 Meeting started Mon Sep 7 14:03:08 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:03:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:13 The meeting name has been set to 'rally' 14:03:41 oanufriev: ping 14:03:44 \o/ 14:03:45 o/ 14:03:50 ~o~ 14:03:54 amaretskiy: ping 14:04:00 hi 14:04:41 hi 14:04:57 hi 14:05:31 boris-42: pong 14:05:59 hi 14:07:30 Guys, I have a critical bug-fix for networkcontext+nova-net(v2.1 endpoint) - https://review.openstack.org/#/c/220991/ 14:07:41 *folks :) 14:08:17 andreykurilin: why this work before? 14:08:42 boris-42: nova V2.0 ignores redundant parameters 14:09:14 andreykurilin: boris-42 seems neutron's python api changes 14:09:22 kun_huang: it's not neutron api 14:09:25 andreykurilin: hard to define n-net as critical :) 14:09:26 :) 14:09:27 kun_huang: it's nova api 14:09:36 yfried: heh 14:09:40 kun_huang: actually our gates are failing 14:09:48 kun_huang: so it's quite critical* 14:10:12 yfried: it's critical for our gates:) since we uses it there 14:10:56 andreykurilin: reviewed. need jenkins to approve 14:11:13 I forgot a link to nova schema - https://github.com/openstack/nova/blob/ae55af90d64fbc0447104c1fb9949501c834085c/nova/api/openstack/compute/schemas/networks.py#L30 14:12:05 btw, I have another patch related to V2.1 14:12:08 https://review.openstack.org/#/c/220726/ 14:12:10 andreykurilin: boris-42: so anything else on this subject? 14:12:21 andreykurilin: +2 from me 14:12:32 yfried: I believe we can move on 14:12:36 #topic [yfried] "Compose scenario" vs "new input task format 14:12:55 andreykurilin: why can't I see your 2nd patch in Rally dashboard? 14:13:15 yfried: hm...I don't know:( 14:13:20 boris-42: ^ ? 14:13:57 boris-42: I'm reviewing based on these filters. it should be under "Ready for Review" 14:14:22 нyfried topic is another lol=) 14:14:43 boris-42: sorry, still hanging on the previous. so - moving on 14:14:48 re topic 14:15:24 we have 2 specs (one merged one under review) links in the agenda (boris-42 could you please post them?) 14:15:49 #link https://github.com/openstack/rally/blob/master/doc/specs/in-progress/new_rally_input_task_format.rst 14:15:58 #link https://review.openstack.org/#/c/215762/ 14:16:32 yfried: ^ 14:17:26 mkrcmari and myself would like to make sure that #2 is not included in #1 and that #2 is generally accpetable because this is something that will get a lot of our manual testing team to use rally 14:17:55 btw mkrcmari is aix 14:18:04 yfried: so I don't think that spec about new task fromat is related to this new spec 14:18:16 aix: ping* 14:18:16 =) 14:18:34 * aix is here 14:18:35 yfried: there are 2 different things 14:18:50 boris-42: let me draft the difference as I understand it and tell me if you agree 14:18:52 yfried: so format just allows you to execute series of ready scenarios* 14:19:03 yfried: and this thing should be able to combine parts 14:19:12 yfried: and these parts can't be scenarios 14:19:26 yfried: I believe the good thing is to combine current atomic actions* 14:19:31 so format spec will allow you to say run "A, B, A(different input), C, D, B(same input),..." and also (maybe) run A and at the same time run B 14:19:50 boris-42: ^ 1sec 14:20:31 yfried: so what I think is that this should be done as a part of spec that refactors rally scenario utils 14:20:47 the 2nd spec is about concatenating multiple scenarios to create some high level scenario (build network, build volume, boot VM into previous resources, collect Ceilometer input about network, volume and VM) 14:22:06 boris-42: how? 14:23:05 yfried: nope they are not 14:23:31 boris-42: please explain, as I think we got out of sync 14:23:51 yfried: new input task format is about running N benchmarks one by one or in parallel in the same context 14:24:11 boris-42: which is the same as I've said, isn't it? 14:24:13 yfried: mostly for load + monitoring + HA 14:24:18 yfried: nope it is not 14:24:30 yfried: there is no idea to use output of firs benchmark as a chain 14:25:00 boris-42: the last part is about "compose" 14:25:02 yfried: + you are running fully first benchmark, then fully second benchmark, then fully third benchmark 14:25:07 yfried: nope it is not 14:25:20 yfried: there is big difference 14:25:56 yfried: between running 3 different Scenarios (fully A, fully B, fully C) and running load (A, B, C n times) 14:26:32 boris-42: and you say the 1st option is what new format is about? 14:26:37 or second? 14:27:03 yfried: first is about input task 14:27:08 boris-42: yep 14:27:09 yfried: second is comopsing benchmark 14:27:29 yfried: so in one case you are running 3 scensarios in second you are running 1 scenario 14:27:40 yfried: and that is huge difference 14:27:43 boris-42: so about input task - it will allow us to run A(args1), B, A(args2) 14:27:49 boris-42: ^? 14:28:00 yfried: like it is described... 14:28:04 boris-42: ok 14:28:09 boris-42: and about "compose" 14:28:11 : 14:28:45 yfried: in case of input task each scenario has own sla/context/runner 14:28:53 boris-42: ^ agreed 14:29:08 yfried: in case of compose you have one runner and one context for all frankenstain * 14:29:19 boris-42: ^ agreed as well 14:29:19 all/whole* 14:29:35 boris-42: and you are not ok with "compose", are you? 14:29:52 yfried: I am ok with compose 14:30:01 yfried: I am not ok with making it from scenarios* 14:30:06 boris-42: because I like it and I've seen demand for it around my colleagues 14:30:39 yfried: I like as well functionallity but it should be implement in another way 14:31:00 boris-42: using atomic-actions would require (IMO) to make atomic a plugin 14:31:02 yfried: as I said it should be done as a part of scenario utils refactoring 14:31:17 yfried: and that is okay 14:31:38 boris-42: could you please suggest the general idea of how? 14:31:41 yfried: validation and types will be plugin as well 14:32:58 yfried: so just make them plugins that are easy to use in context and scenarios and compose scenarios 14:33:23 boris-42: ok, so compose is way down the road and would require me to work on the "scenario utils refactoring" spec. I'd appreciate your help on that 14:33:25 yfried: in case of atomic we can use output 14:33:31 boris-42: ok 14:33:39 yfried: yep I will help 14:33:56 yfried: but I believe if we desing everything well it won't take forever to cover both cases 14:34:05 yfried: or even 3 14:34:19 boris-42: so please post a summary of this to as review on that spec and let's combine both specs 14:34:27 yfried: making it simple to use atomics in context, remove wrappers and do compose scenario 14:34:52 yfried: so I put actually pretty the same information in that spec 14:35:03 boris-42: also, can/do we have a way to see approved specs in readthedocs? 14:35:14 yfried: so it can be done 14:35:24 yfried: like we are doing for feature request 14:35:31 boris-42: exactly 14:35:38 yfried: but it is not done yet 14:36:37 #topic [boris-42] Rally Info & Plugin reference 14:36:58 Okay guys I did a bunch of work related to removing rally info and creating rally plugin 14:37:06 that contains same functiaonllity 14:37:18 and in future will manage rally plugins 14:37:59 #link https://review.openstack.org/#/c/217005/ 14:38:01 ^ here is the chain 14:38:03 boris-42: it makes it clear that ctx and runners have bad doc 14:38:11 yfried: yeeeppp 14:38:24 yfried: as well that we don't have good docs for base classes 14:38:31 boris-42: I'll open bugs about it 14:38:37 yfried: like context.Context, scenario.Scenario, scenario.Runner 14:38:39 boris-42: what about deprecation rally info or removement? 14:38:53 andreykurilin: so I did the next, i removed all commands 14:39:11 andreykurilin: except rally info find, rally info list where I wrote it's deprecated use rally plugin find 14:42:19 any questions? 14:42:49 nope 14:42:52 #topic [boris-42] What is important for Rally 0.1.0 release 14:43:10 so I believe there are 3 things 14:43:18 that we should do in this release more 14:43:25 1) rally info stuff 14:43:31 2) rally task abort 14:43:36 3) rally reports 14:43:47 ^ yfried ikhudoshyn andreykurilin please review these patches 14:43:57 sure 14:44:56 btw, which is for 'task abort' 14:45:20 I've seen one which looked abandoned for me 14:45:43 ? 14:46:04 about 'task abort': I'll try to check it locally and post new change 14:46:15 ikhudoshyn:https://review.openstack.org/#/c/161636/ 14:46:46 what is 'aborted' in gerrit btw? 14:48:19 ikhudoshyn: ?) 14:48:50 boris-42: the patch that you pointed is marked as 'aborted' )) 14:49:00 ikhudoshyn: ;) 14:49:06 looks like something not really good for me 14:50:11 haha, got it, I feel especially dumb today)) 14:50:12 ikhudoshyn: it's name of patch lol 14:50:19 ikhudoshyn: =) 14:50:25 okay so let's end this meeting 14:50:27 see you next week 14:50:33 #endmeeting