17:00:49 <mtreinish> #startmeeting qa
17:00:50 <openstack> Meeting started Thu Sep 11 17:00:49 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:55 <openstack> The meeting name has been set to 'qa'
17:01:06 <mtreinish> hi, who's here today?
17:01:08 <mkoderer> \o/
17:01:14 <mlavalle> hi
17:01:15 <coolsvap> hello
17:01:15 <jlanoux> hi
17:01:17 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_September_11th_2014_.281700_UTC.29
17:01:19 <dmorita> o/
17:01:23 <mtreinish> ^^^ Today's agenda
17:01:31 <andreaf> o/
17:02:09 <mtreinish> ok, let's get started I'm sure more people will trickle in later
17:02:17 <mtreinish> #topic  Summit topic brainstorming (mtreinish)
17:02:26 <mtreinish> #link https://etherpad.openstack.org/p/kilo-qa-summit-topics
17:02:42 <mtreinish> I just wanted to put up another reminder about this etherpad in case someone missed it
17:02:56 <mtreinish> if anyone has a topic they'd like to discuss at summit please add it there
17:03:27 <mtreinish> when we get closer to summit I expect we'll have a good portion of a meeting or 2 dedicated to sorting through and prioritizing what's listed there
17:03:32 <mkoderer> do we already know how many slot we have?
17:03:38 <mtreinish> mkoderer: not yet
17:03:51 <mkoderer> k
17:04:02 <mtreinish> also the format will probably be different with the last day being kinda of like a midcycle
17:04:12 <dkranz> o/
17:04:16 <mtreinish> so even if a topic doesn't get a slot we can discuss it during the free form part
17:04:42 <mtreinish> which is why I wanted to give everyone more time so we've got a nice long list :)
17:04:48 <andreaf> I've seen the new topic from dmorita - I hope the work I did on auth framework in tempest will help, but it would be great to discuss it and collect more input
17:05:25 <mtreinish> andreaf: yeah that might fall into the tempest-lib discussion too
17:05:38 <mtreinish> because it's really about stabilizing the auth interface
17:06:02 <mtreinish> anyway does anyone have anything else to bring up about this topic?
17:06:06 <mtreinish> otherwise let's move on
17:06:53 <mtreinish> #topic Specs Review
17:07:23 <dkranz> mtreinish: Results of bug day?
17:07:28 <mtreinish> does anyone have any open specs reviews that they'd like to get eyes on
17:07:33 <mtreinish> dkranz: heh, that's a spec?
17:07:49 <dkranz> mtreinish: No, it was before on the agenda. But we can wait.
17:08:09 <mtreinish> dkranz: oops, forgot to refresh before the meeting
17:08:15 <mtreinish> stale page
17:08:16 <dkranz> mtreinish: np :)
17:08:24 <mtreinish> dkranz: we'll do that topic next
17:09:07 <mtreinish> if no one has an open spec to bring up (which isn't surprising given our place in the cycle) let's move on
17:09:08 <andreaf> mtreinish: so the only spec I have is https://review.openstack.org/#/c/118352/ I just uploaded a new patchset
17:09:21 <dkranz> mtreinish: Don't seem to be other active specs now
17:09:30 <mtreinish> andreaf: yeah, I haven't looked at the lastest rev, but it can probable be fast pathed in today or tomorrow
17:09:56 <mtreinish> oh I guess the only other thing is to review dhellmann's rss patches
17:10:07 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs+branch:master+topic:rss-feed,n,z
17:10:14 <mtreinish> should be simple enough to review
17:10:51 <mtreinish> #topic Results of Bug Day
17:10:56 <mtreinish> dkranz: ok you're up
17:11:13 <dkranz> There was not that much participation in bug day
17:11:22 <dkranz> We still have 75 New
17:11:47 <dkranz> There were a lot of triage issues with logs no longer being available
17:12:06 <dkranz> I think we need to triage in real time and proposed a weekly rotation
17:12:15 <jlanoux> is there any requirements to triage?
17:12:29 <dkranz> jlanoux: not really
17:12:34 <mtreinish> dkranz: well that happens if the logs are old enough. I don't think we can even keep 6 months anymore
17:12:45 <dkranz> mtreinish: right
17:12:52 <jlanoux> dkranz: ok, so non-core can do it?
17:12:55 <mtreinish> jlanoux: I think there is a tempest bug group in lp, but joining it should be open
17:13:03 <dkranz> mtreinish: and we only keep logstash for 9 days
17:13:11 <jlanoux> mtreinish: ok
17:13:45 <mtreinish> dkranz: one thing I've been thinking about doing is having someone who watches the bug list and keeps on top of triage
17:14:04 <mtreinish> some of the other teams have been doing this and it's working well
17:14:08 <mkoderer> should we have a weekly rotation.. so every week somebody that is responsible for bugs comming in?
17:14:35 <dkranz> mkoderer: that is what I proposed
17:14:53 <mkoderer> dkranz: ok... fine for me
17:15:00 <jlanoux> dkranz: mkoderer +1
17:15:03 <dkranz> I'm not sure we will find a volunteer to do it always
17:15:14 <coolsvap> mtreinish, drankis mkoderer I am in for a week in a month +1
17:15:24 <mtreinish> I asked gmann ealier and he said he'd be willing to do it
17:15:33 <mtreinish> but sure we can give a weekly rotation a try
17:15:41 <dkranz> mtreinish: great. even better.
17:16:02 <dkranz> mtreinish: It could work either way as long as there is a volunteer.
17:16:49 <dkranz> mtreinish: The question is whether we consider it to be a Core reviewer task or not
17:16:50 <coolsvap> mtreinish, i think we can have a group of 3-4 people and a volunteer who can always delegate to someone if he's busy/unavailable at certain periond
17:17:28 <dkranz> Yes, a volunteer is a degenerate case of rotation
17:17:42 <mtreinish> dkranz: I think doing at least some bug triage is a responsibility for a core reviewer
17:17:55 <dkranz> mtreinish: that is why I suggested rotation
17:18:06 <mtreinish> yeah I'm thinking if gmann is willing to watch the list and track things we do that
17:18:14 <mtreinish> and still have a weekly rotation of people doing triage
17:18:21 <dkranz> mtreinish: because I doubt any core reviewer wil volunteer full-time
17:18:40 <dkranz> mtreinish: ok, that is fine. I will post an etherpad with weeks/dates and send something out to the list
17:19:06 <mtreinish> dkranz: ok cool, and talk to gmann about it too
17:19:14 <dkranz> mtreinish: so what exactly will gmann do that you discussed?
17:19:21 <dkranz> as a volunteer?
17:19:29 <mtreinish> #action dkranz to work on setting up a weekly bug triage rotation
17:20:01 <mtreinish> mostly keep on top of tracking bug stats, and bringing bugs to attention of people if they need it
17:20:16 <dkranz> mtreinish: ok, so not really triage
17:20:22 <dkranz> mtreinish: that's fine
17:20:48 <dkranz> mtreinish: he can poke people who signed up for a week but are not active enough :)
17:21:00 <mtreinish> well triage would be part of it, but it was more of an administrative thing
17:21:03 <mtreinish> dkranz: yep :)
17:21:07 <dkranz> mtreinish: ok
17:21:25 <dkranz> mtreinish: I think that's it for that topic
17:21:32 <mtreinish> ok then let's move on
17:21:35 <andreaf> mtreinish: before you go to bp
17:21:41 <andreaf> mtreinish, forgot to mention https://review.openstack.org/#/c/94741/
17:21:48 <andreaf> mtreinish, ssh auth spec
17:22:07 <mtreinish> andreaf: heh, well that falls to me :)
17:22:11 <andreaf> mtreinish, it would be good to either get more feedback on it or approve it
17:22:14 <mtreinish> I'll take a look at it after the other one
17:22:20 <andreaf> mtreinish, thanks
17:22:50 <mtreinish> I am thinking we might need to revise the spec process a bit in kilo, but I'll save that discussion for later
17:22:55 <mtreinish> ok let's move on
17:22:57 <mtreinish> #topic Blueprints
17:23:22 <mkoderer> I'd like to give an update regarding negative testing
17:23:30 <mtreinish> mkoderer: ok
17:23:35 <dkranz> dpaterson could not be here but said he is going to push another patch for the resource cleanup
17:23:40 <mkoderer> mtreinish: we can close the schema unification bp
17:23:42 <dkranz> today
17:23:57 <mtreinish> mkoderer: ok cool, I'll do that now
17:24:10 <mkoderer> but we have some issues with the exiting schemas
17:24:25 <mkoderer> we never acutually verfied that there are working
17:24:36 <mkoderer> so 2 of 4 are broken :(
17:24:44 <mtreinish> nice...
17:25:01 <mkoderer> I tried to fix it with auto validation
17:25:02 <mkoderer> https://review.openstack.org/#/c/120033/
17:25:23 <mkoderer> and I will fix the broken ones
17:26:03 <mtreinish> mkoderer: ok cool. is the validation going to run as a unit test?
17:26:20 <mkoderer> mtreinish: no because it has to send a request to a real server
17:26:27 <mtreinish> ah, ok
17:26:30 <mtreinish> yeah I see that now
17:26:42 <mkoderer> mtreinish: so it's a gate test
17:27:05 <mkoderer> ah and I have to update the documentation again :)
17:27:24 <mkoderer> k that's it from the negative testing front
17:27:38 <mtreinish> ok thanks
17:27:49 <andreaf> mtreinish, updates from my side
17:27:54 <mtreinish> andreaf: ok
17:28:33 <andreaf> mtreinish, the multi-auth one, I'm waiting on scenario migration and test accounts to be through as they'll make my life easier then I'll resume work there
17:28:48 <mtreinish> ok that makes sense
17:29:00 <mtreinish> I'll defer that to kilo then, because it probably can't be done until then
17:29:11 <andreaf> mtreinish: yes
17:29:31 <andreaf> mtreinish, test-accounts is progressing well there is a failure on the large opts test which I need to debug else it's almost done
17:30:11 <andreaf> mtreinish: and we support the current configuration as well for backward compatibility so the periodic job will keep running
17:30:34 <mtreinish> andreaf: is that job also in the experimental pipeline?
17:30:44 <mtreinish> because I think it'll be good to test it before we land that change
17:31:09 <andreaf> mtreinish, uhm I have to check
17:31:19 <mtreinish> andreaf: no big deal if it's not, it's easy enough to add
17:31:43 <mtreinish> I'd just like to avoid a big surprise there when we land it
17:32:11 <andreaf> mtreinish, ok I'll check and add it in case it's not there
17:33:26 <mtreinish> andreaf: ok is there anything else?
17:33:46 <andreaf> mtreinish: on the scenario migration, as masayukig is not here, we also have good progress (MERGED:9, APPROVED:3, SUBMITTED:4, NOT YET:2)
17:34:06 <andreaf> mtreinish, plus the final cleanup of things
17:34:08 <mtreinish> cool, yeah that's moving a long
17:34:58 <andreaf> mtreinish, there's a problem with this kind of migration and copy of code in that if the original code is updated in the meantime the change could be lost if we don't recheck on cleanup
17:35:17 <andreaf> mtreinish, so I think we'll need careful review on cleanup again
17:35:25 <mtreinish> yeah, that's a good point
17:35:55 <andreaf> mtreinish, all from me
17:35:58 <mtreinish> ok
17:36:07 <mtreinish> does anyone else have an update on an open bp
17:37:08 <mtreinish> ok then I'll bring up tempest-lib now
17:37:17 <mtreinish> #topic tempest-lib first release
17:37:41 <mtreinish> last week we created the openstack/tempest-lib repo
17:38:03 <mtreinish> the first release was going to be just the cli testing framework
17:38:11 <mtreinish> I've got 3 patches up for review at: https://review.openstack.org/#/q/status:open+project:openstack/tempest-lib,n,z
17:38:23 <mtreinish> which clean a few things up
17:38:35 <mtreinish> and after that I think we're ready for the first push to pypi
17:38:51 <dkranz> mtreinish: cool. I have a question about the next step.
17:38:53 <mtreinish> that will allow us to switch tempest over to use the lib for cli tests
17:39:04 <mtreinish> and then start the migration of those tests into the clients
17:39:05 <mtreinish> dkranz: sure
17:39:21 <mtreinish> I wanted to make sure everyone was comfortable with the interface after those 3 patches
17:39:36 <dkranz> The real bang-for-the buck here will be moving the tempest service base classes and rest clients so can be used by project func tests
17:40:06 <dkranz> We already identified the "_, body = ..." issue with a proposed solution
17:40:07 <mtreinish> dkranz: well the rest client is next on the list for migration
17:40:33 <dkranz> mtreinish: IMO, we should fix the _, body issue first
17:40:48 <mtreinish> dkranz: would we handle that in the rest client or the service clients though?
17:40:49 <dkranz> It is now an ugly scar
17:41:13 <dkranz> mtreinish: Sorry, I thought you were including the service clients
17:41:23 <dkranz> mtreinish: This is definitely handled in the service clients
17:41:36 <mtreinish> maybe, but the first step is the rest client and the required auth and cred stuff
17:41:43 <dkranz> mtreinish: right
17:41:52 <mtreinish> because that's an easy win
17:41:58 <dkranz> sure
17:42:04 <mtreinish> we can sit on the service clients for a bit longer and fix the warts first
17:42:15 <andreaf> dkranz, mtreinish that brings up a general question I have about how we proceed for the migration - we stop accepting patches as soon as a piece of code is proposed for migration to tempest-lib?
17:42:26 <dkranz> mtreinish: agreed,
17:42:46 <andreaf> andreaf, what about all the in-flight patches that affect rest-client? they will need to be split
17:42:48 <mtreinish> andreaf: yeah, once something is migrated we should ideally tell them to move over to the lib
17:43:10 <dkranz> I think we need to specify a cut-off date
17:43:19 <dkranz> ANd make sure we review patches in flight before then
17:43:20 <mtreinish> andreaf: just rebase them on the lib, the only thing that should be different is the path
17:43:23 <andreaf> mtreinish, perhaps we should keep an etherpard to track migration so people now what to expect / and how to review
17:43:26 <dkranz> and reject them after
17:43:33 <mtreinish> dkranz: yeah that's a good idea
17:44:00 <mtreinish> anyway, we've got a bunch of topics left still
17:44:09 <mtreinish> so we can discuss this in -qa after the meeting
17:44:26 <andreaf> ok
17:44:33 <mtreinish> so let's move on
17:44:41 <mtreinish> #topic Devstack
17:44:47 <mtreinish> dtroyer: around?
17:46:05 <mtreinish> well if dtroyer shows up we can come back to devstack
17:46:15 <mtreinish> unless anyone else has something to discuss about devstack
17:46:57 <mtreinish> ok, then let's move on
17:47:03 <mtreinish> #topic Grenade
17:47:20 <mtreinish> jogo, sdague: any updates on grenade this week?
17:48:32 <mtreinish> ok, does anyone else have anything to discuss about grenade then?
17:48:53 * mtreinish wonders if there is a correlation between projects in bash and meeting topics...
17:49:12 <jogo> mtreinish: no updates on my end
17:49:18 <mtreinish> jogo: ok
17:49:26 <mtreinish> ok let's move on
17:49:32 <mtreinish> #topic Critical Reviews
17:49:33 <jogo> mtreinish: oh we did land the ironic sidways upgrade stuff
17:49:41 <mtreinish> #undo
17:49:42 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3114110>
17:49:47 <mtreinish> jogo: ok, cool
17:50:03 <mtreinish> that's the bit adam_g was working on to do a juno bm -> juno ironic migration
17:50:31 <mtreinish> jogo: will that logic also work for a n-net -> neutron migration when the time comes?
17:50:34 <jogo> mtreinish: yup we expect to have to do a similar thing for nova-network -> neutron
17:50:52 <mtreinish> cool
17:50:58 <mtreinish> markmcclain: ^^^ just a heads up
17:51:21 <mtreinish> ok if there's nothing else on grenade we can move on
17:51:35 <mtreinish> #topic Critical Reviews
17:51:50 <mtreinish> ok, does anyone have a review they'd like to get eyes on
17:52:01 <dmorita> I have one.
17:52:06 <dmorita> #link https://review.openstack.org/#/c/117193/
17:52:36 <dmorita> As i wrote in agenda, I am working on moving checker of response code to service clients
17:52:44 <dmorita> for Swift
17:53:13 <mtreinish> dmorita: ok, yeah I see the notes from the agenda
17:53:16 <dkranz> mtreinish: This is the same old issue
17:53:31 <mtreinish> that discussion came up before, the decision we reached is that swift is the exception to that stability rule
17:53:34 <dmorita> The problem is which idea to choose
17:53:34 <mtreinish> because it predates it
17:53:42 <dkranz> right
17:53:43 <notmyname> hi
17:53:52 <dmorita> hi, notmyname
17:54:00 <notmyname> no, I don't agree that we are changing any stability rules
17:54:10 <notmyname> we aren't changing any response codes with this patch
17:54:15 <mtreinish> it's why we define the valid success_codes in rest client
17:54:19 <dkranz> notmyname: no one said we were
17:55:27 <mtreinish> notmyname, dmorita: I'll chime in on that review later today, assuming the code is good I'll give it a +A
17:55:27 <notmyname> ok, so what's the status on it? what's the path forward
17:55:43 <dkranz> notmyname: I gave my +2 and I hope it will be approved as is.
17:55:50 <notmyname> also note https://review.openstack.org/#/c/120622/
17:56:02 <mtreinish> notmyname: it was just oomichi forgot the discussion from last year on this topic
17:56:13 <dkranz> right
17:56:18 <notmyname> oh, I didn't know it was a previous conversation
17:56:33 <dkranz> notmyname: yes, you and I had it :)
17:56:37 <notmyname> heh, ok
17:56:41 <dkranz> among others
17:56:50 <notmyname> anyway, I wanted to be clear that we're not looking for API instability or changing things out from under clients
17:57:08 <notmyname> I think I can say with integrity that swift is pretty good at api stability
17:57:35 <dkranz> notmyname: I know, it is just that swift's definition is different the others but we are accepting that
17:57:39 <notmyname> but at the same time, it is very much our intention that swift clients should be looking at response code classes
17:57:47 <dmorita> Yes. i think so too. but double check is necessary IMHO
17:57:51 <dkranz> of course
17:58:10 <mtreinish> ok, with ~2min left, does anyone else have any other reviews to bring up that could use extra eyes
17:58:20 <coolsvap> mtreinish, I would like to highlight the fact that XenServer CI -1 might be affecting code reviews
17:58:40 <mtreinish> coolsvap: as in we're breaking xenserver ci
17:58:53 <mtreinish> or that people aren't looking at reviews because of a -1 from xenserver ci?
17:59:08 <coolsvap> mtreinish, i think that way
17:59:30 <mtreinish> coolsvap: which way?
17:59:30 <coolsvap> since the Verified column is -1 even though jenkins is +1
17:59:43 <mtreinish> oh, ok
17:59:48 <dkranz> Yes, I had trouble with this as well
17:59:58 <mtreinish> yeah that's something to just keep an eye out for
18:00:07 <mtreinish> xenserver ci might have a false negative just like jenkins
18:00:10 <dkranz> mtreinish: IMO, it is a bug that the high-level view shows -1 if jenkins says +1
18:00:22 <clarkb> note you can server with label:verified>=1,jenkins
18:00:27 <clarkb> and get what jenkins +'d
18:00:37 <mtreinish> dkranz: well unless we broke something for the non-jenkins env
18:00:45 <mtreinish> like a hardcoded libvirt assumption in a test
18:00:57 <dkranz> clarkb: I think the issue is with the review dashboard that sdague provided
18:00:57 <mtreinish> clarkb: cool thanks
18:01:07 <dkranz> of course we should not ignore the -1
18:01:19 <mtreinish> dkranz: you can update that, it's just a repo
18:01:22 <mtreinish> anyway we're at time
18:01:26 <mtreinish> thanks everyone
18:01:32 <mtreinish> #endmeeting