17:02:03 <sdague> #startmeeting qa
17:02:04 <openstack> Meeting started Thu Nov 14 17:02:03 2013 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:07 <openstack> The meeting name has been set to 'qa'
17:02:34 <sdague> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_November_14_2013
17:02:50 <sdague> quick roll call of who's here via: o/
17:02:58 <sdague> (meetbot actually records that)
17:03:04 <dkranz> o/
17:03:07 <mkoderer> o/
17:03:15 <sdague> afazekas: ?
17:03:31 <sdague> I know mtreinish is popping around in .jp this week on vacation
17:03:53 <sdague> #topic Possible Meeting Time change to include .jp (sdague)
17:04:06 <sdague> ok, so this is something I know we talked a bit about at the summit
17:04:11 <mkoderer> +1 for that
17:04:24 <mkoderer> I think we should ask giulivo
17:04:44 <sdague> agreed
17:04:54 <sdague> just pinged him to jump in channel
17:05:09 <sdague> I expect the tz shift might have made people forgetful :)
17:05:12 <dkranz> morning in us is the only time that works for us/europe/jp
17:05:14 <sdague> hey giulivo
17:05:38 <sdague> dkranz: well, the .jp folks said they could do 6am - 9pm their time
17:05:49 <mkoderer> so which timeframe are we talking about
17:05:55 <mkoderer> ok
17:06:14 <sdague> so what I was actually thinking might be best is to do the oscilating meeting
17:06:37 <mkoderer> it's UTC+09:00
17:06:52 <sdague> https://wiki.openstack.org/wiki/Meetings#Metering_team_meeting
17:07:03 <sdague> is how Ceilometer does it
17:07:29 <sdague> so I was thinking maybe do those same time blocks that they use, but on the alternate weeks
17:07:48 <sdague> which would make every other week work for .jp
17:08:07 <sdague> and not make the .eu people stay up super late all the time, just on some weeks (if they can make it)
17:08:27 <sdague> and as long as we take votes to the ML, instead of in IRC, it would be inclusive
17:08:27 <dkranz> So for us east that would be 10am and 4pm, plus one hour when DST?
17:08:28 <mkoderer> I am fine with that
17:08:45 <sdague> dkranz: yes
17:09:04 <sdague> giulivo: you have an opinion here?
17:09:07 <dkranz> So the europe night owls could do both :)
17:09:12 <sdague> yes, exactly
17:09:51 <sdague> it feels like it would be a more global friendly way of handling it, and let us bring on more folks from around the globa
17:09:53 <sdague> globe
17:09:56 <giulivo> well I'm a bit worried oscilating meetings
17:10:01 <dkranz> sdague: Works for me
17:10:11 <giulivo> could be forgiven
17:10:11 <sdague> giulivo: ok, please share the concerns
17:10:18 <dkranz> giulivo: I think oscilating is ok as long as it is easy to remember
17:10:19 <sdague> that's why I brought it up for discussion
17:10:54 <dkranz> sdague: I presume the ceil thing means "date is odd" or "date is even"
17:10:55 <giulivo> what would be an alternative timeframe anyway?
17:11:01 <sdague> does everyone use google calendar? I could make sure that we have an updated calendar entry
17:11:14 <sdague> dkranz: no it's on ISO-week % 2
17:11:22 <dkranz> sdague: urck
17:11:31 <mkoderer> so if we take 6am jp time this will be 11pm euope time right?
17:11:36 <sdague> mkoderer: yes
17:11:47 <sdague> so the other alternative is to fix to that schedule I think
17:11:54 <giulivo> auch, that probably won't work for jp anyway
17:11:58 <sdague> because I really do want to be inclusion of the .jp team
17:12:04 <sdague> giulivo: they said they could do 6am
17:12:11 <sdague> but that's the earliest they could do
17:12:33 <giulivo> I could manage to do it later actually
17:12:37 <sdague> which we could do, but that will force the .eu folks to be up all the time.
17:12:40 <dkranz> Understandable :)
17:12:56 <mkoderer> I am for oscilating it
17:13:03 <giulivo> afazekas, ?
17:13:34 <sdague> giulivo: yeh, I pinged afazekas earlier, did get a response, not sure if he's on right now
17:14:08 <sdague> if the concern is forgetting the meeting, is that addressable via a google cal + a reminder?
17:14:49 <sdague> ok, so because we're a little low on quorum, how about we agree to take to the list, to get other feedback from folks
17:14:49 <mkoderer> giulivo: what is your concern with oscilating the meetings?
17:14:51 <giulivo> sdague, well it's about organizing things around it to avoid conflict
17:15:02 <giulivo> but it's three of you voting for oscilating so, np with that
17:15:27 <mkoderer> sdague: yes let's take it to the ML and we vote there
17:15:28 <sdague> giulivo: well, we should at least make sure either of those schedules do actually work for the .jp team :) so I'll take to the list anyway
17:15:50 <dkranz> sdague: Sounds good.
17:15:56 <sdague> #action sdague to take schedule change proposals to the list for -qa meeting
17:16:18 <sdague> #topic Blueprints
17:16:39 <sdague> ok, first off, I haven't started digesting blueprints yet out of our sessions
17:17:07 <sdague> I was talking with russellb this morning, and this afternoon I'm going to work on a purge script to drop the old bp so we don't have untargetted crud in our tracker
17:17:36 <mkoderer> sdague: I already added the negative test bp
17:17:47 <sdague> mkoderer: awesome
17:18:05 <sdague> yeh, any help in creating blueprints out of the etherpads would be awesome
17:18:18 <sdague> even for areas that you aren't the one directly working on
17:18:39 <sdague> next week I'm largely out of commission, so I won't be able to do it until the week after
17:18:43 <dkranz> sdague: Is this the slot to discuss how we coordinate new scenario tests?
17:18:50 <sdague> dkranz: just about
17:19:12 <sdague> or... actually mkoderer put the negative testing one in here
17:19:19 <sdague> mkoderer: was there something specific on that?
17:19:30 <dkranz> sdague: Just an update I think
17:19:37 <mkoderer> sdague: yep just a update
17:19:39 <sdague> ok, mkoderer fire away
17:20:04 <mkoderer> dkranz and I started with some design sessions
17:20:06 <mkoderer> #link https://etherpad.openstack.org/p/bp_negative_tests
17:21:10 <mkoderer> we agreed to start on a prototype implementation which will be available next week hopefully :)
17:21:11 <sdague> nice, that looks really cool
17:21:16 <sdague> that would be awesome
17:21:18 <sdague> you guys rock
17:21:26 <dkranz> sdague: Marc is going to put some prototype code
17:21:32 <sdague> I like the declaritive language for it
17:21:47 <dkranz> sdague: And I am going to make sure the other apis don't have complexity that is missing from this mode.
17:21:49 <mkoderer> sdague: I think we could also produce positive tests with it
17:21:57 <dkranz> sdague:   ^^ model
17:22:31 <sdague> I think my only suggestion is whether we could declare relative to the REST end point, instead of our internal code
17:22:43 <dkranz> sdague: We discussed exactly that issue
17:22:48 <sdague> even if that required another mapping layer from rest end point to internal client / library
17:22:55 <sdague> because it would be easier to onboard folks then
17:23:01 <dkranz> sdague: I was intially inclined toward rest but there are two issues
17:23:04 <sdague> and know relative to the API how we were doing
17:23:14 <dkranz> sdague: 1. The way it is now covers json and xml
17:23:39 <dkranz> 2. The way it is now avoids the problem that in the http, some arguments are embedded in the url and some in a json dict
17:24:14 <mkoderer> but the drawback is that json schemas are more problematic to link
17:24:21 <dkranz> Should get some more thought perhaps
17:24:25 <sdague> dkranz: sure, it just means there is a lot of tempest specific context in the definition. It would be nice to hide that if possible
17:24:44 <sdague> anyway, just a thought, I don't want it to derail the great work here
17:24:52 <dkranz> sdague: I agree if there was a use case outside of tempest. Not sure there really is at the moment.
17:25:18 <sdague> dkranz: honestly, I'm less concerned with the use case outside of tempest, as it meaning if we refactor tempest internals the defs break
17:25:33 <dkranz> sdague: Anyway, we are talking a small prototype now
17:25:38 <sdague> yep, agreed
17:25:39 <mkoderer> let's bring the prototype up and we discuss it in more detail
17:25:44 <mkoderer> yep :)
17:25:47 <sdague> I think that prototype will make things clearer
17:25:58 <sdague> but nice start regardless
17:26:16 <dkranz> ok, I think that's it.
17:26:27 <mkoderer> yes thats it
17:26:49 <sdague> ok, lets do the scenario planning at the end, as it's not on the agenda
17:26:53 <sdague> #topic Neutron
17:27:14 <sdague> EmilienM said he wouldn't be able to make it, but he provided some status in -qa earlier
17:27:43 <sdague> he's got some reviews up for negative tests that salvatore thinks the neutron team needs to nail down behavior
17:27:49 <sdague> but it's not quite ready for review yet
17:28:05 <sdague> I would just say in general, please prioritize neutron reviews
17:28:30 <mkoderer> yes maybe the guys making those test could directly ping in IRC if they want
17:28:36 <sdague> as that team is working really hard now to fix neutron issues, and we'd really like to be part of the solution
17:28:42 <sdague> mkoderer: yes, good point
17:28:45 <dkranz> sdague: +1
17:28:46 <mkoderer> so I will directly have a lool
17:29:00 <mkoderer> s/lool/look/
17:29:01 <sdague> #info please prioritize neutron reviews to help close neutron qa gaps
17:29:13 <sdague> also, there will be a code sprint in Montreal in Jan
17:29:24 <sdague> the details are starting to show up on the ML
17:29:42 <sdague> the intent being a neutron / qa push to close remaining gaps before icehouse-2
17:29:55 <sdague> so if anyone wants to participate, just keep an eye on it on the ML
17:29:55 <anteaya> mkoderer: I will send them over
17:30:03 <sdague> anteaya: thanks
17:30:04 <dkranz> sdague: I saw that. Hoefully there is a way for those not in Montreal to join, at least for part of it.
17:30:14 <mkoderer> anteaya: great
17:30:23 <anteaya> dkranz: can you attend?
17:30:26 <sdague> dkranz: it's going to be a code sprint, so joining will probably just mean staying active on IRC
17:30:33 <anteaya> would love to have lots of qa there
17:30:36 <sdague> dkranz: it's only a 5 hr drive for you, right? :)
17:30:43 <dkranz> sdague: Right
17:30:50 <anteaya> so come
17:30:55 <anteaya> email me your email address
17:30:57 <dkranz> sdague: If the roads are clear
17:30:59 <sdague> montreal was chosen for proximity reasons to mtreinish and I
17:31:04 <anteaya> anteaya at anteaya dot info
17:31:05 <sdague> dkranz: that's why I have a subaru
17:31:12 <dkranz> sdague: :)
17:31:17 <anteaya> dkranz can you take the train?
17:31:24 <dkranz> anteaya: No
17:31:29 <anteaya> :(
17:31:36 <dkranz> THere is none
17:31:37 <sdague> the train lines around here to montreal are pretty odd and slow
17:32:01 <dkranz> anteaya: I'm not sure if I can make it or not.
17:32:18 <anteaya> fair enough, please email me anyway
17:32:21 * sdague grew up in vermont, understand the weird trains pretty well
17:32:28 <anteaya> then we can firm up later
17:32:38 <sdague> ok, I think we can move on to next topic
17:32:53 <sdague> #topic How should we sync the teams (neutron/scenario test)? One BP with work items, bugs or ML? (mkoderer)
17:32:56 <sdague> mkoderer: you are up
17:33:15 <mkoderer> so I just added this topic since I saw the discussion about syncing all the teams
17:33:36 <mkoderer> so EmilienM  asked about neutron testing and on the ML was about scenario testing
17:34:28 <mkoderer> I have the feeling nobody want to track it in launchpad
17:34:54 <sdague> yeh, I think we're going to need to limp through with various ad-hoc things in this cycle until we get enough of storyboard working to run with it
17:34:59 <dkranz> mkoderer: Is this the same issue I sent to the ml yesterday, about tracking scenario work in general?
17:35:17 <sdague> so at this point, I'm completely happy with various groups picking whatever works for them to be productive
17:35:25 <mkoderer> dkranz: yes, there was the very same discussion with neutron testing
17:35:32 <sdague> if that's a google doc, cool. etherpad, cool. wiki, cool.
17:35:38 <dkranz> I didn't see the message from EmilienM
17:36:02 <sdague> I think we should have 1 high level blue print for each of these efforts, just so we can keep an overall eye on progress
17:36:05 <mkoderer> dkranz: it was on irc about how we want to sync the effort in neutron
17:36:11 <dkranz> mkoderer: o
17:36:13 <giulivo> sdague, that means you won't use gerrit and text files for that though, correct?
17:36:22 <sdague> but the details should be wherever the people doing the work want to
17:36:26 <sdague> giulivo: that's an option too
17:36:55 <sdague> but again, I feel like we don't have an efficient standard way to manage the details, so I don't want to impose one on people
17:37:09 <dkranz> sdague: Right
17:37:15 <mkoderer> sdague: ok so if I have time  I will open up these bp's tomorrow
17:37:29 <sdague> I'm completely ok with a blueprint with a description, and a link to however the group is managing the details
17:37:32 <dkranz> sdague: How about either doing what we talked about yesterday using gerrit, or a blueprint named "Scenario:  ..."
17:38:01 <sdague> dkranz: are you talking about 1 blueprint per scenario?
17:38:07 <sdague> because I think that will be too heavy
17:38:16 <dkranz> sdague: Yes.
17:38:28 <dkranz> sdague: That's why I suggested the gerrit thing.
17:38:38 <dkranz> sdague: I was just agreeing we should not impose it.
17:38:43 <mkoderer> mhh I think it should be one bp with different work items
17:38:51 <sdague> dkranz: ok, I think we are on the same page
17:39:17 <giulivo> I'm with dkranz on the gerrit idea, scenarios usually have good descriptions so that should be the first "patchset": a description of the scenario test
17:39:18 <dkranz> mkoderer: We are talking about all scenarios. Many are not specific to a project.
17:39:18 <sdague> just to be clear, we really do need a blueprint for each high level thing. Like "Scenario Test Additions in Icehouse"
17:39:36 <dkranz> sdague: That's fine.
17:39:38 <sdague> but the details really can be elsewhere
17:40:02 <sdague> mkoderer: right, the problem is the only way to do work items in blueprints is the whiteboard, which is pretty wonky
17:40:12 <mkoderer> sdague: I know :|
17:40:21 <dkranz> sdague: I was more concerned with avoiding dup and allowing for comments
17:40:36 <giulivo> dkranz, +1
17:40:38 <dkranz> But a master blueprint should be fine
17:40:53 <dkranz> And completed scenarios can be added so we have a list
17:40:56 <sdague> dkranz: right, so if the top level blueprint takes you to an etherpad or file in gerrit, or however the team wants to manage that, it should funnel everyone there
17:41:06 <dkranz> sdague: Right
17:41:22 <sdague> so a unified entry point to get folks to the right detailed discussion
17:41:28 <dkranz> Yes
17:41:32 <mkoderer> that's sounds like a plan
17:41:58 <sdague> and then agressively go close new blueprints that pop up that look like dups, and drive those folks in through the master blueprint
17:42:09 <giulivo> 12
17:42:13 <sdague> policing that second bit is going to be important to make sure we don't fragment
17:42:18 <dkranz> +1
17:42:27 <mkoderer> +1
17:42:30 <sdague> cool
17:42:37 <giulivo> actually I don't have credentials in launchpad for that
17:42:49 <sdague> giulivo: ok, lets fix that after the meeting
17:43:02 <sdague> everyone with +2 should have that, but it's not automatic
17:43:41 <mkoderer> ok don't know if I have these permissions
17:43:46 <sdague> fwiw, the new thinking on storyboard that mordred and I are pushing is make storyboard a rest api first
17:43:55 <sdague> with sample scripts to manipulate it
17:44:01 <sdague> and let people build UIs later
17:44:16 <sdague> which I think would work really well in our workflow
17:44:33 <sdague> and ensure we can write lots of scripts to support the workflows we need
17:44:54 <sdague> ok, next topic
17:44:58 <sdague> #topic Onboarding documentation - where should we put it? (mkoderer)
17:45:10 <sdague> mkoderer: you up again :)
17:45:19 <mkoderer> I got these action item from the summit
17:45:31 <mkoderer> any ideas where this document should be stored?
17:45:33 <mkoderer> wiki?
17:45:41 <sdague> mkoderer: actually, I'd suggest putting it in tree
17:45:48 <giulivo> yeah in tree
17:45:54 <sdague> doc/source
17:45:55 <dkranz> sdague: +1
17:45:57 <mkoderer> sdague: ok cool
17:46:11 <sdague> publishes to http://docs.openstack.org/developer/tempest/ on merge
17:46:23 <mkoderer> great I will have a look
17:46:36 <sdague> awesome
17:46:41 <mkoderer> if I find some time I will push it
17:46:42 <mkoderer> :)
17:46:46 <sdague> nice :)
17:46:51 <sdague> +1 to more docs
17:46:55 <mkoderer> thats all
17:47:11 <giulivo> sorry guys, how is the onboarding different from the README?
17:47:27 <sdague> I was actually thinking that maybe we need a REVIEWING.rst as well, which I might bang out a proposed version on the airplane some time next week
17:47:47 <sdague> just to make sure we write down all our assumptions about reviewing, and that we are on the same page
17:48:00 <sdague> giulivo: I think it's more extensive than what's there
17:48:07 <sdague> README is mostly a quickstart kind of approach
17:48:22 <sdague> but with the docs tree we can have more complicated chapter model to target different audiences
17:48:25 <sdague> which is good
17:48:31 <mkoderer> yes it will have a lot of details that arent needed in readme
17:48:43 <sdague> there is plenty of confusion, and writing things down will help
17:48:55 <sdague> mkoderer: thanks again for championing this
17:49:06 <sdague> ok, last topic
17:49:06 <mkoderer> I am quite sure it will cause a lot of discussions
17:49:10 <mkoderer> yep
17:49:15 <sdague> mkoderer: yep, and it will be great :)
17:49:25 <sdague> #topic Critical Reviews (sdague)
17:49:25 <EmilienM> mkoderer: o/
17:50:05 <mkoderer> should we quickly talk again about neutron testing?
17:50:43 <sdague> mkoderer: we can take that to -qa I think
17:50:46 <mkoderer> sure
17:51:04 <sdague> anyone have some reviews they need eyes on that are falling behind?
17:51:41 <sdague> in general I'd like to see the Nova v3 reviews make more progress, though it looks Ken'ichi has been all over those over night
17:51:48 <sdague> which is awesome
17:51:56 <mkoderer> I have a trouble with a review
17:51:59 <mkoderer> #link https://review.openstack.org/#/c/51122/
17:52:15 <mkoderer> seems that it's a problem due to py2.7
17:52:17 <sdague> ok, is it debug issue?
17:52:23 <sdague> ok, that's something we should try to sort out
17:52:48 <mkoderer> afazekas told me that I should skip one test for py2.7
17:52:54 <mkoderer> I need to have a closer look
17:53:01 <sdague> I'd rather not skip 2.7
17:53:06 <sdague> that seems like the wrong approach
17:53:13 <mkoderer> sdague: I know ;)
17:53:13 <sdague> so let's try to get to the bottom of the issue
17:53:23 <sdague> after lunch I'll try to help loook
17:53:25 <mordred> sdague: what did I do?
17:53:32 <mordred> ah. nm
17:53:36 * mordred read scrollback
17:53:45 <sdague> ok, any other critical reviews?
17:54:22 <sdague> #topic Open Discussion
17:54:23 <dkranz> sdague: There actually aren't any that are old.
17:54:29 <giulivo> an on-the-fly topic
17:54:30 <dkranz> sdague: But the queue is still pretty long
17:54:37 <dkranz> giulivo: Go ahead
17:54:37 <giulivo> I noticed the ironic tests addition
17:55:01 <sdague> dkranz: yeh, the queue is long, I was going after it oldest to newest, but I think a lot was lag leading up to summit
17:55:18 <sdague> giulivo: go for it
17:55:33 <giulivo> but that doesn't seem easy to gate, anyone looking into that?
17:55:54 <sdague> giulivo: they have a virtual bare metal setup ... which I thought landed in devstack
17:55:57 <sdague> maybe not yet
17:56:19 <sdague> they will also be doing real baremetal on some tripleo clouds, and report as 3rd party testing
17:56:20 <dkranz> The last comment says there are patches after which this can run
17:56:44 <sdague> so once they get that, we could use the 3rd party testing results to help us know the code runs as well
17:57:16 <giulivo> need to learn what that 3rd party directory is :)
17:57:33 <sdague> giulivo: so our 3rdparty directory is for 3rdparty APIs
17:57:40 <dkranz> sdague: mtreinish pushed the config sample file change which will cause more pain. It is blocked on rebase.
17:57:41 <sdague> but this is going to be like SmokeStack
17:57:49 <dkranz> sdague: Are you able to push it?
17:57:52 <sdague> dkranz: I can rebase it
17:58:04 * sdague adds to afternoon queue
17:58:11 <dkranz> sdague: How do you do that?
17:58:22 <sdague> git review -d #####
17:58:26 <sdague> then rebase on master
17:58:29 <sdague> then repush
17:58:42 <dkranz> sdague: Oh, I thought you had a way without "taking" it
17:58:48 <dkranz> sdague: That's fine
17:58:55 <sdague> it only changes the committer, he'll still get author for it
17:59:12 <dkranz> sdague: Got it. We should do that more often.
17:59:30 <sdague> yeh, typically I only do that if I know the person is going to be away for a week
17:59:44 <sdague> because I really want folks to come back around and pay attension to their patches
18:00:00 <sdague> and when people don't, I use it as a signal to not prioritize reviewing their code
18:00:06 <sdague> because they aren't attentive
18:00:34 <sdague> ok, I think we're at the end of time
18:00:40 <sdague> so thanks for coming, see you on -qa
18:00:45 <sdague> #endmeeting