17:00:33 #startmeeting qa 17:00:34 Meeting started Thu Oct 9 17:00:33 2014 UTC and is due to finish in 60 minutes. The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:37 The meeting name has been set to 'qa' 17:00:40 hi who's here today? 17:00:46 hello 17:00:51 #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_October_9th_2014_.281700_UTC.29 17:00:55 ^^^ Today's agenda 17:01:02 hello 17:02:08 dkranz, mkoderer, andreaf_, afazekas: around? 17:02:13 here 17:02:17 hi 17:02:27 yo 17:02:30 ok let's get started 17:02:33 hello~ 17:02:44 #topic Summit topic brainstorming (mtreinish) 17:03:02 so the tenative timeslots have been posted for the design summit 17:03:35 by my count we've got 7 regular slots and 1 day full day meetup room (shared with relmgt and infra) 17:04:01 so I'd like to dedicate next week's meeting to discuss the priorities and plan out our sessions 17:04:44 * psedlak ~ delay hi 17:04:51 dtroyer: there is an absence of devstack and grenade topics on the brainstorming list 17:05:10 I think we should have at least one session on those 17:05:50 is everyone ok with doing the planning meeting next week? if so I'll send a note out to the ML about it 17:05:57 yes 17:06:34 maybe it's been the timeslots, but the last couple of devstack sessions were either highly focused (mini-meetup stuff?) or just talking about what happened (ml). 17:06:58 so much of the planning for devstack comes out of the other areas to support what goes on there. 17:07:53 dtroyer: ok, well depending on how the breakdown looks maybe an earlier combined grenade/devstack session and then just do the meat of it during the mini-meetup 17:08:33 I was thinking to focus on Friday and not use up a sesion for status and stuff we could do on the ml 17:08:45 ok, that works too 17:08:52 mtreinish: I would propose a double slot for "tempest in the brave new world", which will spill over anyway 17:09:19 dkranz: ok, do you want to put a comment on that in the etherpad? 17:09:44 it might be a disjoined double session if your cross-project topic on it gets picked 17:10:03 mtreinish: True. When will those get picked? 17:10:14 dkranz: dunno 17:10:17 ttx: ^^^ ? 17:11:23 aside from the open question, which I'll find an answer to, is there anything else to discuss on this topic for right now? 17:12:32 hi sorry i am a bit late. 17:12:32 #topic Specs Review 17:12:51 so dkranz you put this on the agenda, you've got a new spec correct? 17:12:57 mtreinish: yes 17:13:38 mtreinish: I am eager to see tempest-lib have service clients and this is a necessary step, at least 17:13:45 #link https://review.openstack.org/#/c/126004/ 17:14:12 mtreinish: There were no negative comments about this on the ml when I first brought up the thread 17:14:27 not that that proves anything :) 17:14:54 dkranz: heh, well sdague had a similar proposal at one point, and my only concern was refactor cost 17:15:11 but let's get some eyes on the review 17:15:24 mtreinish: It's pretty much the same kind of work as moving checking to the clients which was not so bad 17:16:06 mtreinish: I know it is not required but I am really hoping that in-project tests will share the same clients and configuration as tempest 17:16:10 dkranz: looks nice to me, I'll review it in details this week 17:16:20 mtreinish: so we can retain a real test suite even after many tests are not in tempest anymore 17:16:53 andreaf: thanks 17:17:44 dkranz: well we're purposely not putting any config file in tempest-lib so the config file won't be shared between tempest and functional tests 17:18:00 mtreinish: not the file itself, but the conf "interface" 17:18:17 mtreinish: there is no reason that could not be shared 17:19:10 mtreinish: I would hate for in-project tests and similar tests in tempest using different names for the parameters that are configured 17:19:56 oh, yeah if they're using service-clients that are in tempest-lib that wouldn't be an issue 17:20:24 but I get what you're saying, we can try to make sure that we're thinking about that when we do the migration 17:20:40 ok, does anyone else have a spec they'd like to bring up? 17:20:51 mtreinish: right. It goes back to Maru's idea that func tests should be runnable in real and specific environments 17:21:57 #topic Blueprints 17:22:07 #link https://blueprints.launchpad.net/tempest/juno 17:22:37 so coming to the end of the cycle we're actually in a better spot than I thought we'd be a few weeks ago 17:22:47 we've closed a couple more bps 17:23:00 and I think we're close to closing a couple more soon 17:23:10 does anyone have an update on an open bp? 17:23:17 * mtreinish looks at andreaf 17:23:31 yes to the https://blueprints.launchpad.net/tempest/+spec/tempest-client-scenarios is completed 17:23:38 like branchless-tempest-extensions? 17:23:52 salv-orlando: yep 17:24:07 I have pushed the devstack patch that uses verify-tempest-config -ur 17:24:23 and abandoned the tempest patch which we do not need anymore 17:24:27 all I need now is reviews. 17:24:35 salv-orlando: cool do you have a link 17:25:05 mtreinish: client-checks-success is done except for compute. But might as well do that along with getting rid of _ 17:25:07 mtreinish: https://review.openstack.org/#/q/status:open+topic:bp/branchless-tempest-extensions,n,z 17:25:34 salv-orlando: it'll be good to try and get that landed before the cycle ends, so we can finally properly split extensions on releases for the gate 17:26:01 mtreinish: test accounts is quite close - only 1 patch outstanding - at least for the scope of the bp itself, there will be a part two required to put it in production. We've verified that the new code works fine with tenant isolation off and on, as well as with locking accounts and non-locking accounts 17:26:39 mtreinish: #link https://review.openstack.org/#/c/107685/ 17:27:05 salv-orlando: cool, thanks. I think that -1 will be fixed by https://review.openstack.org/126694 17:27:21 andreaf: yes, that will be awesome to get landed 17:27:29 it's only take >40 revs... :) 17:27:38 mtreinish: indeed... 17:27:54 mtreinish: and finally the resource-cleanup part1 is complete 17:28:26 mtreinish: which is great and we can see in the test-accounts bp now that resource_cleanup is always invoked :) 17:28:37 dkranz: ok, that's fine. I'll retarget it to kilo after the meeting (unless you beat me to it) 17:29:01 mtreinish: and I'm kicking off part2 here: #link https://review.openstack.org/#/c/115353/ 17:29:07 andreaf: cool 17:29:43 so it would be great to get as much feedback as possible on that review as it defines the framework for the rest of the work 17:29:47 dkranz: actually andreaf reminded me I was looking at that post-run cleanup tool, and I don't think it'll work now that resource-cleanup has landed 17:30:11 mtreinish: Why? 17:30:36 dkranz: because it determines the set of resources to clean based on leaked tenants 17:30:51 but we're ensuring that all the tenants get cleared for each run (except for an error) 17:31:17 but if we're not cleaning up the resources created in that tenant the script won't say anything 17:31:17 mtreinish: upz 17:31:37 mtreinish: so we get rid of the tenant now but not any resources in it? 17:31:51 mtreinish: I nope not 17:31:55 we get read of all resources 17:31:59 and last of the tenant 17:31:59 dkranz: well, potentially 17:32:15 but we get read of the tenant even if there was a failure during resource cleanup 17:32:25 s/read/rid 17:32:34 I don't think that script was assuming the existing broken behavior 17:33:01 So are you saying the script is not necessary now? 17:33:13 dkranz: no it is, but we need to rethink how it does detection 17:33:45 anyway we can discuss that after the meeting 17:34:24 mtreinish: ok, the original problem was that many resources have no --all-tenant options so having a tenant is the only way to get at them 17:34:25 ok are there any other bps to discuss? 17:34:55 dkranz: ok, yeah that's what I figured 17:35:39 mtreinish: well I guess no-one had a chance to look at https://review.openstack.org/#/c/115353/ yet 17:35:43 it might require taking this to the ml to try and figure out a common method for everything on how to detect leftover things from a deleted tenant 17:36:04 andreaf: well I havent :) 17:36:39 but yeah if everyone could take a look at that patch, I'd like to get a lot of eyes on it 17:36:43 mtreinish: sure. But it will still work with non-isolated tenants which was really the inspiring use case 17:36:49 mtreinish: I included some docstring with details on how I think the various stages should be used 17:37:05 because we're deciding how to stage our resource creation and teardown 17:37:41 andreaf: ok good, yeah that'll be helpful to figure out how to use it once we land it 17:38:06 ok, let's move on 17:38:14 #topic Devstack 17:38:28 dtroyer: any updates from the world of Devstack? 17:39:14 We've been working on the docs transition and fixing doc errors. 17:39:46 Infra has the place they want to put it, looks like devstack.org is going to wind up being a redirect into (i forget which existing site) 17:40:05 probably docs.o.o 17:40:50 that's where everything else gets published 17:40:56 also preparing for the stable/juno branch; getting the stuff in that makes out lives easier before that, like salv-orlando mentioned earlier, but just as importantly, keeping out kilo-specific stuff before that branch is cut 17:41:22 this is that odd twilight zone transition time 17:41:50 yeah, it's always interesting 17:42:17 that's it for interesting things 17:42:36 dtroyer: ok cool thanks 17:42:57 it'll be good to get the docs auto publishing, I think that'll make things a lot nicer 17:43:15 ok does anyone have anything else on devstack? 17:44:07 #topic Grenade 17:44:39 ok so with the release pending we have to be considering the branch switchover logic here 17:44:53 and with sdague away we need to figure out how to do it 17:45:07 clarkb, jogo: ^^^ do you remember how to do this? 17:45:11 mtreinish: what branch switch-over 17:45:38 mtreinish: oh, you mean grenade and devstack 17:45:39 when juno is released we need to make sure we upgrade from stable/juno -> master 17:45:50 and stable/icehouse -> stable/juno 17:45:51 etc 17:45:52 mtreinish, dkranz: some branch names are hardcoded there 17:45:59 so for a short time we do icehouse to kilo 17:46:08 mtreinish: also in d-g 17:46:20 then we add machinery in d-g and zuul to have jobs for juno to kilo 17:46:33 that also tie icehouse to juno 17:46:51 the biggest part is in d-g 17:47:12 clarkb: ok cool, as long as you've got a handle on the steps I think we'll be fine 17:47:30 I just wanted to make sure someone knew the recipe 17:47:41 ya its not too bad 17:47:53 mtreinish: I remember we had problems last time 17:48:11 we do it conservatively too to avoid badness hence icehouse to kilo for short time 17:48:31 jogo: I think that was related branchless tempest 17:48:50 mtreinish: no, it was related to an old swift proposed branch or something 17:49:12 jogo: oh, ok 17:49:26 yeah I remember something like that now 17:49:48 mtreinish: for grenade we just needsomething like this AFIAK If9417e65c7c54d017c4c847a4020f855684c423c 17:49:50 the swift thing is mostly a non issue now 17:50:07 because we tag intermediate milestones 17:50:43 ok, well we're at ~10min left so let's move on 17:50:51 clarkb, jogo: we can pick this up after the meeting 17:51:07 #topic Bugs 17:51:15 #link https://etherpad.openstack.org/p/Tempest-bug-report 17:51:41 so it looks like we our new bug count dropped a bit this past week 17:51:48 but not nearly as much as last week 17:52:27 either way we're getting closer to the goal of 0 new bugs 17:52:57 it looks this week masayukig was the triage volunteer 17:53:09 and next week gmann volunteered 17:53:17 #link https://etherpad.openstack.org/p/qa-bug-triage-rotation 17:53:31 ok does anyone have anything else to discuss about bugs? 17:54:21 #topic Critical Reviews 17:54:43 ok, with the time remaining does anyone have a review they'd like to get some extra eyes on? 17:54:46 mtreinish: https://review.openstack.org/#/c/123562/ 17:54:55 This was from jogo 17:55:20 dkranz: I was just about to respond to you in -qa 17:55:32 We discussed this at least once before, but should we issue a failure on all failures to delete resources? 17:55:46 I think that is what jogo wants, but his patch won't get it. 17:55:53 dkranz: lets chat in -qa after 17:55:57 jogo: ok 17:56:03 dkranz, jogo: yeah we can pick this up in -qa 17:56:12 ok are there any other reviews? 17:56:59 I guess I'll put up: 17:57:01 #link https://review.openstack.org/123589 17:57:09 not super critical though, just a tox cleanup 17:58:30 mtreinish: I like what the commit message says and tried to review it but am not familiar enough with tox 17:59:19 dkranz: ok, yeah it was the best way I could figure out how to make the envs common but separate 17:59:29 the other option was 2 tox.inis 17:59:40 dkranz: I'll link you the tox config doc 17:59:55 ok if there aren't any other reviews 17:59:59 let's end here 18:00:01 thanks everyone 18:00:08 thanks 18:00:12 #endmeeting