22:00:39 <mtreinish> #startmeeting qa
22:00:40 <openstack> Meeting started Thu Apr  2 22:00:39 2015 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:44 <openstack> The meeting name has been set to 'qa'
22:00:51 <mtreinish> hi who's here today?
22:00:57 <masayukig> o/
22:01:06 <gmann> o/
22:01:16 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_April_2nd_2015_.282200_UTC.29
22:01:24 <mtreinish> ^^^ today's agenda
22:01:56 <dkranz> o/
22:02:07 <mtreinish> dtroyer, jogo: around?
22:02:21 <jogo> o/
22:02:34 <dtroyer> o/
22:02:36 <mtreinish> ok let's get started
22:02:45 <mtreinish> #topic Summit Session Brainstorm
22:02:54 <mtreinish> #link https://etherpad.openstack.org/p/liberty-qa-summit-topics
22:03:07 <mtreinish> so I sent this out to the ml, but figured I'd mention it here too
22:03:22 <mtreinish> I started the etherpad so we can brainstorm topics for design sessions
22:03:41 <mtreinish> I figured we'd follow the same basic process as we used for Paris
22:04:15 <mtreinish> at this point, I'm not sure how many slots we'll have, but I'll ping ttx to find out (IIRC I asked for 5 big session) and 2 or 4 work rooms
22:04:37 <mtreinish> plus a full day for a mini sprint (like we did in paris on fri)
22:05:19 <mtreinish> that's all I had for this, just wanted to bring up the etherpad
22:05:31 <dkranz> mtreinish: ok, looks good
22:06:04 <masayukig> When is the deadline to add topics to the etherpad?
22:06:30 <mtreinish> masayukig: oh, that's a good question
22:06:36 <mtreinish> do you want to say the end of the month
22:06:46 <mtreinish> and we'll do the selection the first meeting in May?
22:07:16 <masayukig> mtreinish: sure, looks good.
22:07:56 <mtreinish> ok, is there anything else on this?
22:08:49 <mtreinish> ok, then lets move on
22:08:56 <mtreinish> #topic Spec Reviews
22:09:07 <mtreinish> does anyone have an open spec review to bring up?
22:09:09 <mtreinish> or discuss?
22:10:20 <mtreinish> I'll take that as a no :)
22:10:26 <mtreinish> let's move on then
22:10:35 <mtreinish> #topic Blueprints
22:10:50 <mtreinish> does anyone have an open bp to discuss this week?\
22:11:53 <mtreinish> well I've got a couple to bring up
22:12:07 <mtreinish> first andreaf asked me to plug the multi-ssh verification bp
22:12:19 <mtreinish> they've got a bunch of patches up to implement it that need reviews:
22:12:25 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/ssh-auth-strategy,n,z
22:12:44 <mtreinish> so if people could keep an eye on those that would be good
22:13:01 <mtreinish> it might be too late in the cycle to get those in by the release, but early L is definitely doable
22:13:20 <mtreinish> the only one I wanted to bring up was the test-accounts-continued bp
22:13:38 <mtreinish> andreaf and I took a first crack at this during the sprint in NYC last week
22:13:50 <mtreinish> we've got patches up to finish the networking support right now
22:14:04 <mtreinish> but they're blocked on a neutron bug which was recently introduced
22:14:35 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/test-accounts-continued,n,z
22:14:58 <mtreinish> so I'm not so optimistic this will make K either :(
22:15:35 <mtreinish> other than that I didn't have any other bps to discuss
22:15:37 <gmann> Cool, ll review those.
22:16:04 <mtreinish> does anyone else have an in progress bp to discuss? Otherwise let's move on
22:16:37 <gmann> mtreinish: for rearrangement for schema. few patches lest
22:16:49 <gmann> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/rearrange-nova-response-schemas,n,z
22:16:57 <gmann> those are easy to review
22:17:14 <gmann> after that that BP can be closed
22:17:18 <mtreinish> gmann: heh, yeah they should be. I'll try to go through them before I call it a day
22:17:23 <mtreinish> cool
22:17:37 <gmann> mtreinish: thanks :)
22:18:08 <mtreinish> ok if there aren't any other bps let's move on
22:19:14 <mtreinish> #topic os-testr added to QA (mtreinish)
22:19:26 <mtreinish> #link http://git.openstack.org/cgit/openstack/os-testr/
22:19:43 <mtreinish> so we added another repo to the qa program this week
22:20:24 <mtreinish> os-testr which is basically a spin off of subunit-trace, subunit2html (the infra script to generate testr_results.html), and a python testr wrapper to replace pretty_tox.sh
22:20:53 <mtreinish> the goal is that this will be the new interface for invoking testr everywhere replacing the pretty_tox scripts which have been copied all around
22:21:11 <mtreinish> subunit-trace and subunit2html are copied pretty much verbatim
22:21:45 <mtreinish> ostestr (the testr wrapper) is still a bit on the rough side, so if people find issues with it or have ui suggestions or improvements feel free to push a patch
22:22:19 <mtreinish> I've already added some of the things we've been talking about for some time like the exclude file so we don't have to manually make those ugly regexes to exclude things
22:22:20 <masayukig> mtreinish: Sure, cool. Is the first consumer Tempest?
22:22:34 <mtreinish> masayukig: yeah tempest and tempest-lib will be the first consumers:
22:22:43 <mtreinish> #link https://review.openstack.org/170272
22:22:49 <mtreinish> #link https://review.openstack.org/170270
22:22:58 <mtreinish> but those are blocked on the requirements freeze
22:23:10 <oomichi_> mtreinish: cool, does it contain TODO file?
22:23:12 <dkranz> mtreinish: maybe we should not remove pretty_tox until ostestr is not rough?
22:23:35 <mtreinish> dkranz: by rough I meant it does basically the same stuff that pretty_tox does (with the same unit test coverage)
22:23:50 <mtreinish> but certain aspects of the ui might change, because I've been doing this on the side
22:23:57 <dkranz> mtreinish: oh, ok ;)
22:24:06 <mtreinish> oomichi_: oh, no not yet, but I can add one
22:24:14 <oomichi_> nice :)
22:24:16 <mtreinish> that's a good idea
22:25:31 <mtreinish> #action mtreinish to add a TODO file to os-testr
22:25:48 <mtreinish> that's all I had on this topic, does anyone else have something else?
22:25:52 <mtreinish> otherwise we can move on
22:26:51 <mtreinish> #topic Devstack
22:27:03 <mtreinish> dtroyer: you're up
22:27:16 <mtreinish> or do you just want to paste your blog post about the sprint and walk away :)
22:27:25 <dtroyer> so we had a good week last week, I've continued working on the venv this week
22:27:34 <dtroyer> that's a good summary
22:28:04 <dtroyer> sdague and I both put up some housecleaning reviews, I anticipate at least one more before we branch stable/kilo
22:28:32 <mtreinish> dtroyer: ok cool
22:28:47 <dtroyer> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint/ is the summary of last week
22:28:55 <dtroyer> DevStack-wise
22:28:57 <mtreinish> dtroyer: btw I think as we do operations for branching stable/kilo we should be updating the qa release wiki page
22:29:03 <mtreinish> to make sure we document all the steps needed
22:29:29 <dtroyer> yup…it's just long enough that I always have to refer back to my notes and even then there is more...
22:30:08 <mtreinish> dtroyer: yeah, I added the one new step I know I added this cycle to the wiki
22:30:18 <mtreinish> and I think there might be others
22:30:30 <dtroyer> FWIW, I'm probably going to be a bit scarce at times for a while
22:30:45 <mtreinish> dtroyer: ok, no worries
22:32:14 <dtroyer> the other interesting bit sorted out recently was the memory consumption by the current pyopenssl, specifically on CentOS.  Just an interesting note that might explain other odd things in low memory situations
22:32:56 <mtreinish> oh, yeah I saw a ML post about that IIRC
22:33:28 <dtroyer> right, but it didn't look like a general-interest post, it started as a glusterfs problem
22:33:40 <dtroyer> anyway, that's it for me
22:34:06 <mtreinish> ok, does anyone have anything else to discuss on devstack?
22:35:11 <mtreinish> #topic Grenade
22:35:26 <mtreinish> jogo: anything on grenade for this week?
22:36:23 <mtreinish> the only update I have this week for grenade is about the future plugin/modular interface
22:36:36 <mtreinish> we did discuss this a bit in NYC, but we didn't formalize a plan yet
22:36:50 <mtreinish> I'm expecting that final plan to come out of summit
22:36:55 <mtreinish> and be an early L thing
22:37:46 <mtreinish> does anyone have anything else to discuss on grenade? (if jogo's not around)
22:38:52 <jogo> mtreinish: all quiet on the western front
22:38:59 <mtreinish> heh, ok
22:39:02 <mtreinish> then let's move on
22:39:26 <mtreinish> #topic Bugs
22:39:36 <mtreinish> gmann: I see you put a bug in the agenda
22:39:47 <gmann> mtreinish: yea
22:39:57 <gmann> #link https://bugs.launchpad.net/tempest/+bug/1436314
22:39:58 <openstack> Launchpad bug 1436314 in tempest "Option to boot VM only from volume is not available" [Medium,New] - Assigned to Soumit (soumit-mishra)
22:40:21 <gmann> actually when nova is configured with boot from volume only then, tempest tests will fail
22:40:55 <gmann> So just need input on those whether we need to support that.
22:41:00 <mtreinish> gmann: I didn't even realize that was a valid nova config tbh
22:41:07 <mtreinish> although I'm not surprised
22:41:31 <mtreinish> gmann: I think if it's a valid use case we should try to support it
22:41:48 <mtreinish> how feasible it is, is a different question though
22:42:06 <mtreinish> how does a server create differ in that env?
22:42:06 <gmann> mtreinish: yea looks like.
22:42:53 <gmann> mtreinish: for nova config if we see - setting max_local_block_devices to 0 for boot from volume only
22:43:34 <gmann> server expect boot-able volume id in request
22:43:39 <dkranz> mtreinish: It seems like the cases where we boot from an image need to specify a volume instead
22:43:51 <gmann> response and all are no difference
22:43:55 <mtreinish> dkranz: ok, that's what I thought
22:43:56 <dkranz> mtreinish: except for image tests I guess
22:44:28 <dkranz> So that is not so hard to implement
22:44:35 <mtreinish> gmann: well how does the api indicate to the user that booting from image doesn't work?
22:44:54 <gmann> dkranz: yea it should be simple to just have those thing on services cleint
22:45:21 <dkranz> mtreinish: the bug report does not have a transcript of the failure unfortunately
22:45:23 <mtreinish> gmann: honestly I might view this as a nova bug. Because if that's the config set for nova, it could easily make the cinder call to convert an image to a volume before doing a boot
22:45:53 <gmann> mtreinish: server create gives error something about bootable device missing
22:45:57 <mtreinish> dkranz: yeah I think before we look into supporting this, the bug should be expanded with more details
22:46:02 <dkranz> mtreinish: It might be some kind of security thing where you are not even using glance
22:46:18 <dkranz> mtreinish: but I really don't know the use case
22:46:57 <mtreinish> dkranz: that seems weird to me, but sure I could see it being the case
22:47:12 <mtreinish> I think I would want to discuss this use case with the nova team before we start making any changes
22:47:37 <mtreinish> because I don't think we have a complete picture of how this is supposed to work/be used
22:48:19 <mtreinish> jogo, mikal: ^^^ you'll be hearing from me... :)
22:48:27 <dkranz> mtreinish: It is worth asking but since it is an explicit option it is hard to see them changing it to what you were suggesting :)
22:49:14 <dkranz> mtreinish: so much for interop
22:49:26 <mtreinish> dkranz: heh, yeah that's my concern
22:49:52 <gmann> dkranz: agree. because doing volume boot automatically might not be good option
22:50:19 <mtreinish> gmann: yeah but even if that's the case if nova has a consistent api response which is unique for this use case
22:50:30 <mtreinish> we could just handle that inside of the service client
22:50:34 <mtreinish> instead of adding another config flag
22:50:47 <mtreinish> but anyway we'll take this up after the meeting in -qa, or the ML
22:51:04 <gmann> mtreinish: yea, ok
22:51:42 <mtreinish> gmann: any other updates on bugs? or should we move on?
22:51:53 <gmann> mtreinish: thats all from my side
22:52:13 <mtreinish> ok, then let's move on
22:52:18 <mtreinish> #topic Critical Reviews
22:52:32 <mtreinish> ok does anyone have any open reviews they'd like to get more eyes on
22:53:49 <dkranz> mtreinish: I have the two to fix non-admin issues
22:54:04 <dkranz> https://review.openstack.org/169882
22:54:22 <dkranz> https://review.openstack.org/166955
22:54:27 <dkranz> They both have a +2
22:54:45 <dkranz> I'm hoping we can get the nightly non-admin job going well.
22:54:55 <dkranz> They both have a +2 already
22:55:10 <mtreinish> dkranz: could you rebase the 2nd one ontop of the first one? That way we can verify both together unbreaks the job
22:55:38 <dkranz> mtreinish: I have actually not done that before. What is the git magic command?
22:55:43 <gmann> dkranz: i looked 166955. its looks good but non-admin job fails. even not finding any related error
22:55:46 <mtreinish> I'll be +A on that after
22:56:15 <mtreinish> dkranz: I would do git review -d 169882 && git review -x 166955 && git review
22:56:31 <dkranz> mtreinish: great
22:56:38 <mtreinish> gmann: yeah both should be needed to fix the job
22:56:57 <gmann> ok
22:57:18 <mtreinish> ok are there any other reviews to bring up?
22:57:33 <oomichi_> I'd like to pick up https://review.openstack.org/#/c/159310/ for moving sever client dev.
22:57:48 <oomichi_> that is a qa-spec review.
22:57:58 <mtreinish> oomichi_: oh, I missed that you respun that. I'll take a look tonight or tomorrow
22:57:59 <oomichi_> s/server/service/
22:58:12 <oomichi_> mtreinish: thanks :)
22:58:14 <dkranz> mtreinish: done
22:58:46 <mtreinish> dkranz: thanks I'll +A the second one after the non-admin job comes back
22:59:25 <mtreinish> ok any last reviews, otherwise I guess we'll call the meeting here
22:59:42 <dkranz> bye all
23:00:19 <mtreinish> #endmeeting