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