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