14:02:21 <andreykurilin1> #startmeeting Rally
14:02:21 <openstack> Meeting started Mon Aug 22 14:02:21 2016 UTC and is due to finish in 60 minutes.  The chair is andreykurilin1. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:25 <openstack> The meeting name has been set to 'rally'
14:02:53 <andreykurilin1> o/
14:02:58 <amaretskiy1> o/
14:03:58 <rvasilets_> o?
14:04:25 <morourke> rvasilets_, it is supposed to look like a person waving to you
14:04:32 <andreykurilin1> :)
14:05:20 <andreykurilin1> amaretskiy1: Have you finished writting agenda?
14:05:23 <andreykurilin1> :)
14:05:46 <rvasilets_> morourke, its anothe smile with a bit bended hand=)
14:05:46 <amaretskiy1> andreykurilin1: no, agenda will be updated in minutes
14:06:03 <andreykurilin1> let's wait several meenutes
14:08:10 <andreykurilin1> hm...
14:08:40 <andreykurilin1> amaretskiy1: I think, we don't need agenda:) let's start without modefying wiki
14:10:55 <andreykurilin1> #topic [rvasilets] Work on Validator related stuff
14:11:13 <andreykurilin1> - Introducing of new Validator base depend on two patches https://review.openstack.org/#/c/297020/ and https://review.openstack.org/#/c/309883/
14:11:21 <andreykurilin1> I will maintain the second one but we need to move on review process on the first patch. As I understand we need to wait Boris review on DB refactoring
14:11:25 <rvasilets_> typing
14:11:48 <andreykurilin1> both two messages were copy-pasted from agenda:)
14:12:06 <andreykurilin1> oh...
14:12:12 <andreykurilin1> they are separate topics
14:12:26 <rvasilets_> Its not a secret that I'm working on the new validators plugin base. I'm stopped on writting validation result into db. Why? - 1) https://review.openstack.org/#/c/297020/ it adds validation_result field into the Task model that I supposed to use 2) https://review.openstack.org/#/c/309883/ it changes task statuses that I also supposed to use
14:13:03 <rvasilets_> So the time of introduction of new plugin basefor validators depend on this two patches
14:13:14 <rvasilets_> first one should be merged by Boris
14:13:43 <rvasilets_> the second one I will maintain as was discussed with Boris
14:13:48 <andreykurilin1> ok, let's make new release this week and merge https://review.openstack.org/#/c/297020/ after it(we will have time to fix it while working on new release)
14:14:04 <rvasilets_> So I suggest to ping more Boris to review first patch)
14:14:26 <rvasilets_> eom
14:14:45 <andreykurilin1> actually I'm ok about 297020
14:14:59 <rvasilets_> Me too)
14:15:29 <andreykurilin1> and since it already has one +2, we can merge it with two more +2 (since it is big change)
14:15:44 <andreykurilin1> let's do it right away after new release
14:16:46 <rvasilets_> So will we cut new release and then merge new db schema?
14:16:50 <andreykurilin1> yes
14:17:18 <rvasilets_> Will the Иoris be the last who should merge that change?
14:17:50 <andreykurilin1> it is not required:) it is opensource))) 3 votes from cores should be enough
14:18:01 <rvasilets_> lol
14:18:08 <amaretskiy1> finally!
14:18:12 <andreykurilin1> I hope boris-42 will not read my message
14:18:13 <andreykurilin1> lol
14:18:19 <amaretskiy1> ups...
14:18:21 <rvasilets_> )))
14:18:42 <andreykurilin1> anything else related to this topic&
14:18:43 <andreykurilin1> ?
14:18:49 <rvasilets_> No
14:18:52 <amaretskiy1> nothing from me
14:19:14 <andreykurilin1> ok, let's move to the next one
14:19:26 <andreykurilin1> #topic  * [amaretskiy] There are proposals for renaming placeholders in HTML report:
14:19:39 <amaretskiy1> let's discuss each proposal separately
14:19:49 <andreykurilin1> 1) Scenario Data -> Workload Data
14:20:03 <amaretskiy1> votes?
14:20:04 <andreykurilin1> I'm ok about this change
14:20:18 <amaretskiy1> that's about our new term
14:20:23 <andreykurilin1> yup
14:20:24 <amaretskiy1> workload === scenario
14:21:35 <rvasilets_> thinking
14:21:41 <andreykurilin1> amaretskiy1: please, share a link to glossary :)
14:21:56 <andreykurilin1> it would be nice to have a link for meeting log
14:22:38 <rvasilets_> okey, possibly yes
14:23:15 <rvasilets_> http://rally.readthedocs.io/en/latest/glossary.html
14:23:29 <rvasilets_> http://rally.readthedocs.io/en/latest/glossary.html#scenario
14:24:11 <amaretskiy1> okay, so desicion is YES
14:24:29 <andreykurilin1> we have broken links in our glossary ;(
14:24:31 <amaretskiy1> *decision
14:24:51 <andreykurilin1> http://rally.readthedocs.io/en/latest/glossary.html#workload is actually http://rally.readthedocs.io/en/latest/glossary.html#id3
14:25:35 <andreykurilin1> 2) Scenario -> Workload
14:25:42 <andreykurilin1> the same
14:25:43 <andreykurilin1> :)
14:25:50 <amaretskiy1> give votes :)
14:25:52 <andreykurilin1> +
14:27:54 <rvasilets_> +
14:28:10 <andreykurilin1> 3) Task Overview -> Summary
14:28:40 <amaretskiy1> tahat's about the table http://logs.openstack.org/66/358566/1/check/gate-rally-dsvm-rally/8f8bac7/rally-plot/results.html.gz#/
14:28:49 <amaretskiy1> *hat's
14:28:53 <amaretskiy1> *that's
14:29:02 <amaretskiy1> top left menu item
14:29:42 <andreykurilin1> hm..
14:29:49 <andreykurilin1> I'm not sure what label is the best
14:30:02 <rvasilets_> I'm for overview
14:30:17 <amaretskiy1> i'm not sure too
14:30:31 <amaretskiy1> however let's consider that "task overview" is not correct
14:30:37 <andreykurilin1> sure
14:30:41 <amaretskiy1> because we can generate report from 100 tasks
14:30:45 <andreykurilin1> let's raise this question at mailing-list
14:30:52 <amaretskiy1> and json files
14:31:03 <rvasilets_> Why? -  google says that summary is a brief description. I guess this is not the best practice to use brief description at the top of report
14:31:42 <rvasilets_> Overview
14:31:45 <amaretskiy1> is this change so important for mailing list? we can keep this as-is and ask boris-42
14:31:49 <rvasilets_> Report overview
14:31:54 <rvasilets_> Tasks overview
14:32:00 <amaretskiy1> "report" is redundant
14:32:16 <amaretskiy1> actually this table is not about tasks (and tasks)
14:32:24 <amaretskiy1> this table is about workloads!!!!
14:32:32 <amaretskiy1> each row is a summary for workload
14:32:51 <andreykurilin1> maybe "worload overview" ?
14:32:55 <astarove> +
14:33:00 <amaretskiy1> workloads overview looks better
14:33:06 <amaretskiy1> workloadS
14:33:12 <rvasilets_> Okey lets called for the times - Overview
14:33:13 <rvasilets_> )
14:33:30 <astarove> sound good to
14:33:30 <amaretskiy1> that looks reasonable :)
14:34:00 <andreykurilin1> 4) in stats table: Total -> Load duration
14:34:32 <amaretskiy1> andreykurilin1: just to be sure: assuming YES for renaming "Task overview" -> "Overview"
14:34:58 <amaretskiy1> Okay, "Total -> Load duration" is the most problematic proposal
14:35:04 <andreykurilin1> +1 since "total" means time of workload + context...
14:35:26 <amaretskiy1> "Total" is actually a problem because people think thi sis a sum af other values in the column
14:36:34 <amaretskiy1> this values is actually a load duration
14:36:48 <rvasilets_> So the proposal is to rename what?)
14:37:18 <amaretskiy1> i'm actually requestion all these renamings because of one this problem which repeats - people get confusing
14:37:38 <amaretskiy1> so this question is the most important
14:38:09 <amaretskiy1> this should not sould like "sum of all atomic actions durations values listed above in this column"
14:38:37 <andreykurilin1> imo, we should raise this rename at mailing too
14:38:38 <amaretskiy1> maybe "iteration duration",  "duration", "load duration", ......
14:39:25 <rvasilets_> For the first time I suggest to make load_duration at report like hyperlink to the proper section at glossary
14:40:11 <amaretskiy1> https://rally.readthedocs.io/en/latest/reports.html#table-with-statistics-data
14:40:53 <amaretskiy1> rvasilets_: hints in report is another question
14:41:15 <amaretskiy1> rvasilets_: we have a lot of options for that - speech bubbles, links, etc
14:41:26 <amaretskiy1> so let's not mix these topics
14:41:53 <amaretskiy1> this concrete question is about renaming (or keeping without change) "Total"
14:42:02 <rvasilets_> Sorry, I don't know that this is another topic
14:48:04 <andreykurilin1> let's discuss "task overiew" and "total" as part of mailing-list
14:48:22 <andreykurilin1> anything else?
14:48:22 <amaretskiy1> ok
14:48:24 <amaretskiy1> yes
14:48:33 <amaretskiy1> i hav ea question about trends report
14:48:52 <amaretskiy1> let's imagine that we have N workloads
14:48:59 <amaretskiy1> and we generate trends report
14:49:02 <amaretskiy1> but
14:49:22 <amaretskiy1> one workloads has some critical failures so all values are "n/a"
14:49:36 <amaretskiy1> we have 2 ways to deal with that
14:50:16 <amaretskiy1> 1) ignore broken workload - this will be silently skipped like it does not exist at all
14:51:15 <andreykurilin1> I dislike such idead
14:51:16 <amaretskiy1> side effect of this solution is that user can be confused since he/she expects N workloads in report (he/she does not know that one (and which one) is broken)
14:51:22 <amaretskiy1> but gets N-1
14:51:33 <rvasilets_> + for dislike
14:51:34 <amaretskiy1> 2) reset all values to zero
14:52:02 <amaretskiy1> in this case the result will be mathematically incorrect because there is actually an absense of result
14:52:47 <amaretskiy1> ideas?
14:53:01 <rvasilets_> how about to raise a big message or an error that we can't build trends for broken workloads?
14:53:31 <amaretskiy1> there actually a success rate chart in trends report so user will see that something get wrong
14:53:46 <amaretskiy1> so reset to zeroes sounds better to me
14:54:01 <amaretskiy1> because missing workload is a cinfusing choice
14:54:08 <amaretskiy1> *confusing
14:54:23 <rvasilets_> this is the choice between to devils
14:54:30 <amaretskiy1> 3rd option? vote for 1) and 2) .....
14:54:30 <rvasilets_> *two
14:54:33 <andreykurilin1> I prefer to leave both options via flag `--skip-broken` or something like that
14:55:14 <amaretskiy1> so reset to zeroes by default but skip if having --skip-broken   - thi sis option 3)
14:55:19 <amaretskiy1> *this is
14:55:31 <andreykurilin1> yes, this is option #3
14:55:35 <amaretskiy1> ok
14:55:40 <amaretskiy1> #vote for 3
14:55:43 <andreykurilin1> :)
14:55:58 <andreykurilin1> I'm for #3
14:56:29 <rvasilets_> I vote for --skip-broken where is the 1) and for generating message that we are unable to generate trend by default
14:59:07 <andreykurilin1> ok, let's finish
14:59:13 <andreykurilin1> move to #openstack-rally
14:59:17 <andreykurilin1> #endmeeting