14:02:50 #startmeeting Rally 14:02:51 Meeting started Mon Mar 7 14:02:50 2016 UTC and is due to finish in 60 minutes. The chair is ikhudoshyn. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:54 The meeting name has been set to 'rally' 14:02:57 hi everybody 14:03:00 hi 14:03:25 rvasilets__: amaretskiy andreykurilin__ boris-42 14:03:35 o/ 14:04:05 o/ 14:04:21 so we dont have much of agenda for today 14:04:39 #topic Open discussion 14:04:49 let's talk about upcoming release :) 14:04:54 so we're automatically in the best part)) 14:05:05 when do we have feature freeze& 14:05:08 ? 14:05:19 amaretskiy: +1 that supposed to be the 1st of my copupe anouncements 14:05:28 of course in the last release day) 14:05:32 amaretskiy: I believe right now 14:05:42 okay 14:05:54 do we have anything important to be merged 14:05:58 ? 14:06:04 yes 14:06:10 ? 14:06:23 i think https://review.openstack.org/#/c/287329/3 is worth this status 14:06:33 this is actually a bug fix 14:06:48 andreykurilin__: and boris said that they will organnize bug fixing hackaton so we have moved release by three days 14:06:49 with the reimplementation of cli command 14:07:33 that is why today and possibly tomorrow we will not have merge freeze 14:07:38 amaretskiy: if it is a bug fix, ff doesn't care about it:) 14:08:02 okay 14:08:09 rvasilets__: bug smash dates: 7-9 14:08:41 its not good to submit re implementation with bug fix) 14:08:46 ok, anything else? 14:09:02 http://logs.openstack.org/62/288362/5/gate/gate-rally-dsvm-keystone-v2api-rally/f934917/rally-plot/results.html.gz#/Dummy.dummy-9 14:09:12 andreykurilin__: okay what is the plain date of release and merge freeze?) 14:09:39 I saw failures like that too much time for last several weeks 14:10:20 rvasilets__: I suppose that we can cut a release at March 10 14:10:45 andreykurilin__: could the issue be keystone-related? 14:11:57 ikhudoshyn: I don't know, but I saw failures only on Dummy scenario #9 14:12:04 hm 14:12:06 we need to discover the issue 14:12:25 we do 14:12:46 any other thing& 14:12:48 ? 14:13:14 if nobody has, I got two 14:13:15 for me nothing now 14:13:28 *from 14:13:48 hi everybody 14:13:49 1) amaretskiy -- I'm interestiong in yr 'get_detailed' work to be done soon) 14:13:54 hi boris-42 14:14:05 boris-42: hi hi 14:14:12 hi 14:14:15 hi 14:14:18 I'm working on DB refactoring and gonna touch this area too 14:14:27 ikhudoshyn: rally task detailed is working 14:14:38 it is)) 14:14:47 but there is a patch from you 14:14:48 ikhudoshyn: however I'm going to make a small change after your comment 14:14:50 ikhudoshyn: amaretskiy cools 14:15:19 amaretskiy: I mean https://review.openstack.org/#/c/287311/ 14:15:58 amaretskiy: jfyi) pls dont leave it for long) 14:16:16 ikhudoshyn: what is wrong with https://review.openstack.org/#/c/287311/ ? 14:16:58 amaretskiy: nothing) It's just I'm the next after you to digg in there 14:17:11 great :) 14:17:26 and the last thing for me 14:17:34 a stupid question 14:17:43 I'll push the patch https://review.openstack.org/#/c/287805/ in a half a hour 14:18:11 amaretskiy: (thumbup) 14:18:34 amaretskiy: ikhudoshyn I am doubt about backward compatiblity here 14:18:39 amaretskiy: ikhudoshyn https://review.openstack.org/#/c/287311/3/rally/api.py 14:18:45 while looking at 'get_task_detailed' i figured out that the code only picks details for just one scenario from thew task 14:19:29 we have extended_results=False by default, so this is backward compatible 14:20:36 guys pls take a look at https://github.com/openstack/rally/blob/master/rally/common/db/sqlalchemy/api.py#L194 14:20:44 and tell me that it's ok 14:20:55 do I miss something? 14:21:38 ikhudoshyn: hm this doesn't seem to be valid... 14:21:59 great, so I'm not an idiot)) 14:22:00 this is ok 14:22:10 amaretskiy: r u sure 14:22:11 this is a way to do safe get query 14:22:11 ? 14:22:25 usually get fails if there is no object found 14:22:35 ikhudoshyn: ah no 14:22:37 so filter(...).first() is safe 14:22:37 the issue is that there could be more than one task_result 14:22:38 ikhudoshyn: it should be ok 14:22:40 returns None 14:22:50 ikhudoshyn: so it will get only one task 14:22:57 ikhudoshyn: but with joinded results 14:23:17 boris-42: really? 14:23:18 ikhudoshyn: so I would agree with amaretskiy that it's ok 14:23:31 ikhudoshyn: it should do so, that code is already forever there 14:23:33 one task could consist several scenarios/workloads 14:23:39 ikhudoshyn: yep 14:23:55 ikhudoshyn: and we are getting ONE task with many results (which means that first) 14:23:58 and each scenario has its own task results? 14:24:04 oh 14:24:06 thanks 14:24:13 this is just a kind of safe query 14:24:35 i was thinking that .first() relates to taskresults 14:25:17 great 14:25:20 ikhudoshyn: yep I thougth about it as well at the first glance=) 14:25:25 i got nothing more to add 14:25:27 ikhudoshyn: until I woke up=) 14:25:41 ikhudoshyn: amaretskiy rvasilets__ guys what about returing BPs 14:26:06 ikhudoshyn: amaretskiy rvasilets__ when I started spending less time on Rally I understood that it's hard to track what is happening in project 14:26:16 #topic hard to track what is happening in Rally 14:26:27 instead of spec or along with? 14:26:52 BPs itself are good 14:26:52 boris-42: no problem with BP, just to decide in which cases we should use specs and BPs 14:27:08 but its harder to work together on the text 14:27:11 no more specs? 14:27:19 amaretskiy: why no more specs? 14:27:33 I've just asked :) no problem 14:27:36 amaretskiy: ikhudoshyn specs are used for discussion 14:27:54 amaretskiy: ikhudoshyn BP for tracking patches (when change contains >1 patch) 14:27:58 so what athe workflow gonna be? 14:28:30 if you are planing big work you are creating BP and just adding bp to commit message 14:28:45 if work requires discussion we are adding spec 14:29:00 after spec is merged we are adding to BP specification url link to spec 14:29:02 and BP contains links to related specs, rignt? 14:29:03 that's all 14:29:08 yep 14:29:12 ok, sounds good 14:29:20 but we don't need to create spec per bp 14:29:29 +1 14:29:33 we should try to avoid specs when it's not required 14:29:45 however BPs seems like will make situation a bit cleaner 14:29:50 what if the feature is small 14:30:00 just BP -- no spec 14:30:03 so there is even one work item 14:30:44 so BP workflow there - I mean BP approval is actually a "discussion" replacement ? 14:31:35 approval is not a discussion replacement 14:31:49 it is a sign that agreement was achieved 14:31:59 use case: small feature but it requires discussion 14:32:22 create BP, discuss in IRC, approve -> work 14:32:46 amaretskiy: if it so small feature that it is 1 patch then nothing 14:32:55 amaretskiy: as I said before above 14:33:06 okay 14:33:08 BP should be used to track features that requires >1 patch 14:33:27 it provide a easy way to find all patches related to the some work 14:36:15 boris-42: that's even better 14:36:25 anything else ? 14:37:39 so I propose to finish for today 14:37:48 ikhudoshyn: one sec 14:37:59 #topic delay release 14:38:11 let's delay release for 3 days because of bus smash effort 14:38:45 boris-42: discussed that already) 14:39:05 and we started feature freeze effective now) 14:40:02 ikhudoshyn: ok great 14:40:13 So I am going to try to finish CTRL + C bug 14:40:15 =) 14:41:05 are we done now? 14:41:09 boris-42: ? 14:41:18 ikhudoshyn: yep ok 14:41:36 so buy everybody 14:41:43 #endmeeting