14:08:24 <rvasilets_> #startmeeting Rally
14:08:25 <openstack> Meeting started Mon Feb  8 14:08:24 2016 UTC and is due to finish in 60 minutes.  The chair is rvasilets_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:08:28 <openstack> The meeting name has been set to 'rally'
14:08:53 <ikhudoshyn> o/
14:08:54 <rvasilets_> Hi there
14:09:12 <redixin> sup
14:09:47 <rvasilets_> I see that there is not s lot of topics in Rally agenda
14:09:56 <ikhudoshyn> ф сщгзду фе дуфые
14:10:00 <rvasilets_> okey lets start
14:10:01 <andreykurilin> o/
14:10:02 <ikhudoshyn> a couple at least
14:10:03 <ikhudoshyn> sry
14:10:17 <rvasilets_> #topic Current state of Rally gate jobs -- testing against Keystone API v2.0 and v3
14:10:46 <andreykurilin> ikhudoshyn: ^
14:10:47 <andreykurilin> :)
14:10:52 <rvasilets_> So ikhudoshyn, share with us
14:11:06 <ikhudoshyn> So I'd like to officially notify everybody that our gate tests that involve devstack..
14:12:48 <ikhudoshyn> all run against Keystone API v3 (the job file is located @ rally-jobs/rally.yaml) except one dedicated job gate-rally-dsvm-keystone-v2api-rally
14:13:27 <ikhudoshyn> The latter runs against v2 api and it runs a task from rally-jobs/rally-keystone-api-v2.yaml
14:14:00 <ikhudoshyn> Rally-CI is yet untouched
14:14:26 <rvasilets_> Will we have the problems if devstack default keystone version would be switched?
14:14:33 <ikhudoshyn> we should agree on whether we'd move it to v3 as well (I beleiwe we should)
14:14:50 <ikhudoshyn> *believe*
14:15:19 <rvasilets_> redixin, previously told that he want to move to v3
14:15:29 <rvasilets_> if i'm right
14:15:41 <rvasilets_> redixin, ^ any comments)
14:15:46 <andreykurilin> it is not possible for all jobs of rally-ci
14:15:52 <ikhudoshyn> rvasilets_: not really. Default Keystone API version is selected via corresponfding env variable -- exactly what is used on gates
14:16:17 <ikhudoshyn> andreykurilin: y?
14:16:23 <andreykurilin> mos job can be broken due to keystone v3
14:17:01 <andreykurilin> but this is just a guess
14:17:12 <ikhudoshyn> andreykurilin: that's ok -- with mos job we should use what mos uses
14:17:32 <redixin> I told? o_O
14:17:46 <ikhudoshyn> andreykurilin: it is still v2.0 api, right?
14:18:21 <andreykurilin> ikhudishyn: as far as I remember - yes
14:18:57 <ikhudoshyn> so for that job we'd keep 2.0
14:19:38 <ikhudoshyn> I actually mean devstack-related jobs
14:19:46 <andreykurilin> :)
14:20:36 <ikhudoshyn> rvasilets_: could we action-item this?
14:20:44 <ikhudoshyn> what's the command
14:20:46 <ikhudoshyn> ?
14:21:30 <rvasilets_> #agreed Leaft mos jobs in rally-ci against v2.0
14:21:52 <rvasilets_> #agreed Left mos jobs in rally-ci against v2.0
14:21:59 <ikhudoshyn> #agreed Move devstack-based jobs in rally-ci to v3
14:22:16 <rvasilets_> Yes, great
14:22:24 <rvasilets_> Anything else?
14:22:27 <ikhudoshyn> that's all from my side
14:22:32 <rvasilets_> okey
14:22:37 <ikhudoshyn> yr turn
14:22:59 <rvasilets_> #topic About changing coverage script behaviour
14:23:57 <rvasilets_> Currently our coverage script unstash stashed files and this is annoying to me
14:24:35 <rvasilets_> If I finished to work on patch and want just to check coverage and quickly send it to review
14:24:55 <rvasilets_> trough tox add -u; tox commit --amend; tox review;
14:25:18 <ikhudoshyn> s/tox/git/
14:25:24 <rvasilets_> I could send to review accidentally stashed files
14:25:36 <rvasilets_> that is not what I expect
14:25:44 <rvasilets_> oh yes
14:25:47 <redixin> it should check diff between your patch and master
14:25:47 <rvasilets_> git
14:26:29 <rvasilets_> we have some magoc in script with stash https://github.com/openstack/rally/blob/master/tests/ci/cover.sh#L25
14:26:40 <rvasilets_> could we avoid it?
14:27:06 <rvasilets_> For Example not to гыу stash фе ше?
14:27:10 <redixin> it can refuse to do anything if there is uncommitted changes
14:27:12 <rvasilets_> *at it
14:27:43 <ikhudoshyn> redixin: +1 that would be nice
14:28:22 <rvasilets_> Why we can't just to checkout to previous patch and check difference
14:28:24 <redixin> I just wonder why do you have uncommited changes when calling tox -ecover
14:28:36 <rvasilets_> because I want
14:28:46 <ikhudoshyn> oh, wait
14:28:48 <rvasilets_> this is my decision at other patch
14:29:14 <ikhudoshyn> stash - is exactly the place to put uncommitted stuff
14:29:27 <redixin> we can't just checkout to master without stashing uncommited changes
14:29:36 <redixin> because it may affect coverage results
14:29:41 <redixin> and it will
14:30:32 <rvasilets_> we could have invariant that you need to run cover only if you commit all changes to this patch
14:30:47 <rvasilets_> It is more obvious
14:31:07 <rvasilets_> than current version
14:31:16 <redixin> so script should show error instead of stashing?
14:31:31 <rvasilets_> for example
14:31:36 <rvasilets_> or warning before
14:31:39 <stpierre> i like that -- the stashing functionality seems like hidden magic
14:31:40 <ikhudoshyn> not sure
14:31:47 <ikhudoshyn> the right algo would be..
14:32:15 <rvasilets_> I suggest to run cover agains patches that don't have stash as invariant
14:32:19 <ikhudoshyn> stash - checkout base - run -checkout yr commit- run - compare - unstash
14:32:28 <rvasilets_> and not to touch stash at the script
14:32:40 <rvasilets_> hi stpierre
14:33:53 <rvasilets_> Current;y we hacve following invariant that if we have stash that its files from current patch
14:33:58 <rvasilets_> I suggest to change it
14:34:03 <ikhudoshyn> rvasilets_: that'd be very tough restriction to work process
14:34:04 <rvasilets_> If we have stash
14:34:32 <ikhudoshyn> rvasilets_: let's rephrase
14:34:35 <rvasilets_> that this is files from not necessarily сгккуте зфеср
14:34:41 <rvasilets_> *current patch
14:35:34 <ikhudoshyn> I propose: we don't run cover if there are uncommitted AND unstashed files. And we remove stashing from cover
14:36:08 <ikhudoshyn> so if you have files you dont want to commit -- you stash it yourself manually and then run cover
14:36:51 <stpierre> agree
14:37:04 <redixin> I can't see any problems here. This script doe's not any stashing if there is no uncommitted changes. If you don't want it to stash, so just stash all by yourself
14:37:09 <stpierre> less magic, more explicit. i think it's reasonable to expect that precondition to run cover
14:37:50 <ikhudoshyn> redixin: on the contrary. If there are uncommitted changes -- cover stashes them
14:37:58 <ikhudoshyn> that's the problem
14:38:17 <rvasilets_> But what I need to do If I have stash from other patch and want to run cover?
14:38:45 <ikhudoshyn> you can have several stashes. it's ok
14:38:58 <rvasilets_> I can't  finish my work on other patch immediately
14:39:15 <redixin> this script will unstash all for you
14:39:41 <ikhudoshyn> redixin: that's exactly what we try to avoid
14:40:05 <ikhudoshyn> like, we don't want automagic -- we'd better controll it manually
14:40:14 <redixin> it will not unstash all, but only what has been stashed
14:41:17 <redixin> ok just file the bug
14:42:03 <ikhudoshyn> I change my mind )
14:42:09 <rvasilets_> uh, okey. redixin looks like this is the most compromise way
14:42:26 <ikhudoshyn> for me it works fine)
14:42:39 <ikhudoshyn> rvasilets_: just "don't hold it that way"
14:42:44 <ikhudoshyn> ))
14:43:03 <rvasilets_> Okey
14:43:30 <rvasilets_> #agreed I will file the bug about coverage
14:43:48 <rvasilets_> Lets move further?
14:44:11 <rvasilets_> Anything to add7
14:44:16 <ikhudoshyn> rvasilets_: while filing the bug pls add details, so we be sure to get yr point right
14:44:32 <ikhudoshyn> do we have any "further" ?
14:44:44 <rvasilets_> #topic Open Discussion
14:45:30 <rvasilets_> Do we have something to discuss?
14:45:48 <redixin> yes
14:45:57 <redixin> heat siege workload )
14:46:06 <redixin> can it be merged?
14:46:15 <rvasilets_> )
14:46:48 <rvasilets_> I was working at weekend at the unit tests magic. I should be green now
14:47:11 <rvasilets_> yep its green
14:47:32 <redixin> great
14:48:19 <rvasilets_> I'll review it more detailed now I think that the finale vote would be from Boris)
14:48:25 <rvasilets_> am I right?)
14:49:09 <rvasilets_> I was needed to add some ceilo tests to pass coverage(
14:49:32 <rvasilets_> Because All added code was covered at 100%
14:49:43 <rvasilets_> but coverage was red
14:50:47 <rvasilets_> Is it normal that directory work load at the top of plugins?
14:50:58 <rvasilets_> redixin, ^
14:51:10 <rvasilets_> at the same level as opensatck and common
14:51:51 <rvasilets_> Also I noticed that in 62 and 74 heat called from different sources https://review.openstack.org/#/c/272510/30/rally/plugins/openstack/services/heat/main.py
14:51:57 <rvasilets_> #link https://review.openstack.org/#/c/272510/30/rally/plugins/openstack/services/heat/main.py
14:52:30 <rvasilets_> This is shouldn't be the problem
14:52:33 <rvasilets_> Okey
14:52:54 <rvasilets_> So I think we could finish meeting?
14:53:27 <andreykurilin> yeah
14:53:41 <rvasilets_> #endmeeting