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