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