17:01:42 <mtreinish> #startmeeting qa
17:01:43 <openstack> Meeting started Thu Feb 26 17:01:42 2015 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:47 <openstack> The meeting name has been set to 'qa'
17:01:57 <mtreinish> hi who's here today?
17:02:09 <cdent> o/
17:02:10 <dtroyer> o/
17:02:21 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_February_26th_2015_.281700_UTC.29
17:02:25 <dkranz> o/
17:02:27 <mtreinish> ^^^ Today's agenda
17:02:30 <mtreinish> kinda full
17:02:54 <afazekas> o/
17:03:15 * jesusaurus is lurking
17:03:16 <mtreinish> andreaf, hogepodge: around?
17:03:27 <mtreinish> ok, lets get started
17:03:27 <sdague> o/
17:03:37 <mtreinish> #topic  Spec Reviews
17:03:40 <dpaterson> o/
17:03:50 <mtreinish> So does anyone have an open spec they'd like to dicuss?
17:04:02 <dpaterson> I've been looking for feedback on:
17:04:13 <dpaterson> link: https://review.openstack.org/#/c/138785/
17:04:16 <k4n0> o/
17:04:22 <mtreinish> #link https://review.openstack.org/#/c/138785/
17:04:44 <mtreinish> dpaterson: oh, sorry I've been meaning to review that
17:05:02 <dpaterson> mtreinish> np
17:05:10 <hogepodge> o/
17:05:12 <afazekas> Can this check can be part of the hacking/pep8 ?
17:05:12 <k4n0> o/
17:05:36 <mtreinish> afazekas: the spec?
17:05:55 <mtreinish> dpaterson: so I'll try to take a detailed look at it today or tomorrow
17:06:16 <dpaterson> mtreinish: danke
17:06:17 <afazekas> mtreinish: The check  for unique tag
17:06:41 <mtreinish> dpaterson: but the proposal was to start with a --help output and work backwards I think we'll probably bikeshed on that for a bit :)
17:06:58 <mtreinish> afazekas: you're jumping the gun a bit...
17:07:21 <mtreinish> does anyone have anything to add on the dpaterson's tempest cli spec?
17:07:28 <mtreinish> or another spec to raise
17:07:57 <sdague> my quick look at dpaterson's spec looks good
17:08:14 <mtreinish> ok, cool
17:08:51 <mtreinish> ok, if there isn't anything else lets move on
17:09:08 <mtreinish> #topic Blueprints
17:09:24 <mtreinish> before I open the discussion to all bp's, hogepodge put one on the agenda
17:10:05 <hogepodge> mtreinish: do you mean the uuid or interop topic?
17:10:15 <mtreinish> hogepodge: the uuid bp
17:10:32 <hogepodge> #link https://review.openstack.org/#/c/157273/
17:10:44 <afazekas> mtreinish: sorry, my prev comments was related to this
17:10:50 <hogepodge> sslypushenko__: and I have been working on implementing uuid tagging and checks
17:11:32 <hogepodge> afazekas: pep8 becomes problematic. It only has lookbehind for one step, which means that you then have to start enforcing ordering of decorators if you require more than one.
17:12:48 <afazekas> hogepodge: As I remember in pep8 module you can have a `global` set, and you can cry if the uuid is repeated or missing
17:13:20 <sdague> hogepodge: yeh, I think a separate tool is probably fine for now, but I think it should live under the pep8 tox taret
17:13:22 <hogepodge> afazekas: parameters to functions are also sanitized. You get back 'xxxxx' instead of the actual value.
17:13:24 <sdague> target
17:13:42 <mtreinish> sdague: yeah, that's the plan it'll be called in the tox pep8 target
17:13:55 <sdague> mtreinish: well... it's not in that patch
17:13:57 <hogepodge> afazekas: So unless I was doing it wrong, I don't think that uniqueness can even be considered in pep8
17:14:10 <mtreinish> sdague: well we can't turn on enforcement until the decorators are added
17:14:17 <mtreinish> I asked them to push the tool up before that
17:14:34 <sdague> oh, ok
17:14:47 <sdague> I change my vote then :)
17:14:51 <hogepodge> I'm ready to send up a large patch with all of the tests tagged.
17:15:14 <mtreinish> sdague: it was just so we could review the tool and make sure it looked sane before we made it gating
17:15:45 <sdague> yeh, my cursory look is that it's probably good enough for this, I think move the ball forward and land it, and improve over time
17:15:53 <mtreinish> sdague: sure
17:16:10 <afazekas> sdague: +1
17:16:16 <mtreinish> hogepodge: do we have the decorator code yet?
17:16:31 <hogepodge> sdague: Yes, I feel the same. It's taken us so long to get here, and I've been getting feedback that uuids are blocking others refactoring work. I don't want to block.
17:16:33 <mtreinish> ignore me, I should look at the latest rev
17:16:36 <sdague> mtreinish: https://review.openstack.org/#/c/157273/19/tempest/test.py,cm
17:16:37 <sdague> yes
17:16:37 <hogepodge> mtreinish: sslypushenko__ added it last night
17:16:54 <sdague> hogepodge: you have my +2
17:17:40 <hogepodge> thanks sdague
17:18:18 <mtreinish> hogepodge: ok, so once the tool patch lands (which will probably be today) we probably should push the patch up soon after
17:18:25 <mtreinish> and we can fast approve it through
17:18:50 <mtreinish> and also update the ML post saying we're doing it so probably rebases aplenty
17:18:51 <hogepodge> mtreinish: It'll be my first priority. It takes moments to tag the entire tree.
17:18:53 <sdague> just add it to the series
17:19:08 <sdague> with the tox change
17:19:09 <mtreinish> sdague: yeah that works
17:19:20 <sdague> so it can come whenever
17:19:58 <k4n0> hogepodge, I can help
17:20:10 <hogepodge> thanks k4n0
17:20:30 <mtreinish> ok, is there anything else on the uuid bp?
17:20:45 <sslypushenko__> one question
17:21:29 <mtreinish> sslypushenko__: ok
17:21:37 * andreaf is here, late
17:21:50 <sslypushenko__> Is it necessary to add functiona ltests fot check tool? or manual tests are enough?
17:22:19 <mtreinish> sslypushenko__: I think manual testing is fine to start, once it's enforcing it'll be self gating to an extent
17:22:39 <sslypushenko__> Ok
17:22:44 <mtreinish> unit tests would be nice eventually, but since it lives in the tools dir that gets tricky
17:22:55 <mtreinish> but either way at this point I don't think we should block on that
17:23:14 <sslypushenko__> I that case functional tests are more preferable
17:23:33 <sslypushenko__> I can add it in other patch
17:23:39 <mtreinish> sslypushenko__: ok cool
17:24:09 <mtreinish> ok are there any other bps to discuss?
17:24:47 <hogepodge> mtreinish: just that unwritten proposal I have for the interop tag
17:25:03 <mtreinish> hogepodge: yeah, I left that as a separate topic later on the agenda
17:25:30 <hogepodge> ok, thanks. sry
17:25:36 <mtreinish> ok let's move on
17:25:46 <mtreinish> #topic Devstack
17:25:59 <mtreinish> dtroyer: so devstack
17:26:27 <dtroyer> so devstack
17:27:01 <dtroyer> I've got the first working version of venvs for Keystone and Glance up, Cinder and Nova have some issues with rootwrap that I'm still working on
17:27:32 <sdague> dtroyer: so... the keystone patch, venvs are mandatory there?
17:27:34 <dtroyer> as a side note, https://review.openstack.org/158376 is a Grenade patch that all of these require so Grenade can duplicate the install sequence
17:27:48 <sdague> that was my only concern in looking at it this morning
17:28:01 <afazekas> dtroyer: the venv looks like not an optional thing after the change, is it by intention or it is bug ?
17:28:09 <dtroyer> sdague: so far, it defaults to individual venvs, but it is totally user-specified based on the value in PROJECT_VENV for each project
17:28:44 <sdague> dtroyer: could we have a global switch for using venvs or not?
17:29:01 <sdague> so that we don't disrupt current testing while we get this in place
17:29:20 <sdague> and that we can try things like turning off requirements enforcement once we have venvs and see how that works
17:29:59 <dtroyer> we could, sure.  I think doing it incrementally might have some benefit though
17:30:19 <dtroyer> should I mash these all into a single review?  they generally arent' that big for each service
17:30:45 <sdague> maybe, except if we're completely changing this with no ability to do system install at all, it's probably something we should raise more visibly at the cross project meeting
17:30:57 <sdague> vs. an optional path that we can get some data on
17:31:25 <dtroyer> it isn't forces, it's just on by default so I can test it...
17:31:48 <sdague> oh, so is there a flag to throw in d-g to turn it off for the gate?
17:32:03 <dtroyer> not a single one, we can add one
17:32:04 <mtreinish> sdague: isn't it a per service flag?
17:32:10 <dtroyer> it's all driven by PROJECT_VENV ATM
17:33:04 <sdague> mtreinish: right, but it seems like "I want global install" shouldn't require 20 unsets?
17:33:15 <mtreinish> sdague: sure
17:33:44 <dtroyer> so we can add one
17:34:08 <sdague> dtroyer: awesome, then I'm ready to approve stuff in
17:34:09 <mtreinish> sdague: so you're proposing that in front of the add venv for X patches, we throw up a global use system install option
17:34:16 <sdague> yeh
17:34:30 <sdague> and that we actually set that as the default for now
17:34:41 <sdague> then have another job on devstack which is venv default
17:34:55 <sdague> so we can see that these changes are working, and what the fallout is
17:35:21 <sdague> especially as I think one of the huge benefits is to not do g-r sync on the venv side
17:36:13 <mtreinish> ok, I'm fine with that
17:36:17 <sdague> at which point we take it to cross project meeting and say, we should do this instead of g-r, which has become too big to maintain anyway
17:36:29 <sdague> and just don't surprise everyone too badly with it
17:37:12 <pennerc> o/
17:37:42 <mtreinish> dtroyer: does sdague's suggested plan work for you?
17:38:07 <dtroyer> yes
17:38:14 <sdague> \o/
17:38:33 <dtroyer> the only other thing I had was the milestone tagging that we started this week retroactively…sdague, want to fill in the background there?
17:38:56 <sdague> oh, sure
17:39:16 <sdague> the neutron functional tests use devstack functions, but not stack.sh
17:39:23 <sdague> which isn't really a stable interface
17:39:39 <afazekas> I have a question regarding to cinder/iscsi/ devstack,  Can we make the lioadm driver default instead of the tgtadm ?
17:39:54 <sdague> there was a cogating failure issue for a while
17:40:14 <sdague> but at the end of the day, cogating really doesn't seem right here, because these are devstack internals
17:40:32 <sdague> so instead, marun and I came up with tagging devstack at milestones
17:40:47 <sdague> so if people want to use internals, they have use a fixed reference tag
17:40:55 <sdague> s/have/can/
17:40:56 <marun> :)
17:41:12 <sdague> then they can roll forward on their own time table, as it's a fixed point
17:41:28 <sdague> which gives us loose coupling
17:41:33 <sdague> which is nice
17:41:40 <mtreinish> sdague: sure I guess that works
17:41:44 <dtroyer> Eventually I would like to define these internals that are useful and maybe even make real interfaces there…more than just what Grenade uses
17:42:07 <sdague> dtroyer: agreed, and we'd have tests on those interfaces at that point
17:42:08 <mtreinish> dtroyer: heh, yeah that's a good plan long term
17:42:24 <dtroyer> devstack-lib is born  ;)
17:42:31 <afazekas> :)
17:42:46 <sdague> but I think this nicely solves the current situation without extra cogating friction
17:43:05 <sdague> anyway, that's that
17:43:16 <sdague> afazekas: on lioadm, how does the cinder team feel about it?
17:43:31 <cdent> I momentarily read that as cogitating friction, which is probably equally true.
17:43:48 <sdague> I'd want thingee or jgriffith to comment on a default change like that
17:43:49 <mtreinish> cdent: heh
17:43:51 <afazekas> sdague, "next cycle" 2 cycles before: https://review.openstack.org/#/c/77630/
17:44:30 <sdague> afazekas: ok, can you get thingee and jgriffith to +1 that patch
17:44:34 <afazekas> sdague: looks like it also would require grenade change
17:44:34 <sdague> then I'm good with it
17:44:55 <afazekas> sdague: ok I'll ping them
17:44:58 <sdague> yeh, well lets get cinder folks on board first
17:45:02 <dtroyer> conceptually I'm fine with it too
17:45:24 <mtreinish> ok, is there anything else on devstack?
17:45:31 <sdague> yeh, tgt didn't even have init scripts in ubuntu for a long time
17:45:33 <sdague> nope
17:45:48 <mtreinish> ok then with ~15min left lets move on
17:46:03 <mtreinish> #topic Codifying test removal procedure: (mtreinish)
17:46:14 <mtreinish> so this is something I wanted to bring up briefly
17:46:33 <mtreinish> in paris we outlined steps for removing tests from tempest in anticipation of people spinning up functional testing
17:46:53 <mtreinish> this past week that's started to happen
17:47:03 <mtreinish> so I figured we should probably codify the rules somewhere
17:47:06 <mtreinish> #link https://wiki.openstack.org/wiki/QA/Tempest-test-removal
17:47:21 <mtreinish> which is basically the summary from the paris session on this
17:47:30 <k4n0> where are the individual projects discussing this?
17:47:59 <dkranz> k4n0: in their project meetings/interactions
17:48:04 <sdague> so I proposed - https://review.openstack.org/#/c/158852/
17:48:10 <k4n0> dkranz, ok thanks
17:48:11 <mtreinish> if there is a proposal from anyone to remove a test from tempest we should push it through that filter
17:48:26 <mtreinish> sdague: sure, I pushed up a -2 to force you to add it to the etherepad :)
17:48:37 <k4n0> mtreinish, how to put a proposal? via a spec?
17:48:49 <mtreinish> k4n0: irc, patch, etc.
17:48:54 <mtreinish> a spec is too heavyweight
17:49:00 <k4n0> mtreinish, ok thanks
17:49:28 <mtreinish> if we want to make the first meeting of everyone month be dedicated to this that would be the next meeting
17:49:38 <sdague> so, I'd recommend putting the etherpad direct link in the -2 in the future
17:49:58 <mtreinish> sdague: oh, sure that's a good idea, I guess I just linked to the wiki page
17:50:17 <mtreinish> I'll tell stevebaker (who beat you to the first removal) to do the same
17:50:39 <dkranz> mtreinish: Is there a reason to do this only once a month rather than weekly on-demand?
17:50:41 <sdague> also, it's not clear how to provide subunit to sql data
17:51:04 <mtreinish> sdague: I'll make the steps a bit more clear. (I'll use your patch as an example)
17:51:24 <sdague> I also think that with Depends-On we can now prevent merge in the wrong order
17:51:26 <afazekas> mtreinish: sbaker removing a skipped
17:51:46 <sdague> so that should probably be part of the process to streamline things
17:52:45 <mtreinish> sdague: sure, assuming the removal is coupled at the same time as the functional test
17:53:01 <sdague> you can still use it as a reference
17:53:10 <mtreinish> sdague: oh, yeah that's true
17:53:15 <sdague> it makes a nice link in gerrit even if the other code is merged
17:54:19 <mtreinish> afazekas: yes, but it is skipped now, but it wasn't always. I think it still should go through this process even if it's just to test it
17:55:04 <mtreinish> anyway if anyone has suggestions on the wiki, etc. Let me know, I imagine this will evolve slightly after the first few removals
17:55:18 <mtreinish> does anyone else have anything else on this?
17:56:10 <mtreinish> ok then let's move on
17:56:19 <mtreinish> #topic Critical Reviews
17:56:38 <mtreinish> there are still a few items left on the agenda, but with ~5min I don't think we'll get a dent out of most of them
17:56:45 <k4n0> https://review.openstack.org/#/c/152878/ , https://review.openstack.org/#/c/157288/ (wishlist)
17:57:01 <mtreinish> so does anyone has a review they'd like extra eyes on
17:57:07 <andreaf> #link https://review.openstack.org/#/c/159267/
17:57:08 <mtreinish> #link https://review.openstack.org/#/c/152878/
17:57:17 <mtreinish> #link https://review.openstack.org/#/c/157288/
17:57:24 <andreaf> next step for auth migration to tempest-lib
17:57:44 <mtreinish> andreaf: ++ yeah that's a good one to prioritize :)
17:58:05 <mtreinish> I had a couple:
17:58:07 <mtreinish> #link https://review.openstack.org/158355
17:58:21 <mtreinish> which was a topic, but it clarifies the docs on the python 2.6 stroy
17:58:45 <mtreinish> and
17:58:48 <mtreinish> #link https://review.openstack.org/157935
17:58:58 <mtreinish> which is the start of a tempest configuration guide
17:59:00 <afazekas> # link https://review.openstack.org/#/c/124998/
17:59:33 <afazekas> # not tempest still does not able to support  shared network test in parallel
17:59:45 <sdague> mtreinish: man, are you picking rst headers at random on - https://review.openstack.org/#/c/157935/4/doc/source/configuration.rst,cm
17:59:59 <afazekas> #note tempest still does not able to support  shared network test in parallel
18:00:13 <mtreinish> sdague: I had to look up subsubheading :)
18:00:42 <sdague> so, in all the docs to date it's been == == (h1) == (h2) -- (h3) ~~ (h4)
18:00:43 <mtreinish> sdague: they're all legit believe it or not
18:01:14 <mtreinish> sdague: http://sphinx-doc.org/rest.html#sections
18:01:32 <mtreinish> afazekas: yeah that's a tricky one
18:01:46 <mtreinish> it's an issue ironic testing has to deal with
18:01:50 <mtreinish> anyway we're at time
18:01:52 <mtreinish> thanks everyone
18:01:57 <k4n0> thanks
18:02:05 <mtreinish> I'll push the topics we didn't get to onto next week's agenda
18:02:05 <sdague> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html
18:02:11 <mtreinish> #endmeeting