17:01:36 <mtreinish> #startmeeting qa
17:01:37 <openstack> Meeting started Thu Aug 27 17:01:36 2015 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:41 <openstack> The meeting name has been set to 'qa'
17:01:45 <mtreinish> hi who's here today?
17:01:50 <jordanP> o/
17:01:52 <austin81> \o
17:01:59 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_August_27th_2015_.281700_UTC.29
17:02:00 <timothyb89> hello!
17:02:03 <mtreinish> ^^^ today's agenda
17:02:15 * rcrit waves
17:02:24 <cdent> o/
17:02:44 <hichihara> hi
17:02:56 <mtreinish> sdague, mkoderer, andreaf, dkranz, mkoderer, dtroyer, afazekas: around?
17:03:24 <dpaterson> o/
17:03:57 <mtreinish> well, lets get started
17:04:06 <mtreinish> #topic Early summit prep (mtreinish)
17:04:25 <mtreinish> so ttx is look for estimates on how much space we'll need for summit
17:04:36 <mtreinish> space is a little tighter so we probably won't get as much
17:05:03 <dkranz> o/
17:05:14 <mtreinish> in YVR we had 5 fishbowls, 4 workrooms, and full day shared contributor meetup
17:05:42 <mtreinish> I was thinking maybe ask for 4 fishbowls, 4 workrooms and the same full day shared at the end
17:06:02 <mtreinish> does anyone have any thoughts on that?
17:06:18 <dpaterson> was the workroom tight in YVR?
17:06:23 <dpaterson> Standing room only
17:06:49 <mtreinish> I think there was 1 or 2 of the 4 which were kinda crowded
17:06:53 <mtreinish> I dont really remember
17:07:49 <mtreinish> also, the fishbowl is a bit more limited in tokyo
17:08:19 <mtreinish> anyway, unless people have complaints with those numbers I'll go ahead and let ttx know
17:08:41 <jordanP> lgtm
17:09:20 <mtreinish> ok, lets move on
17:09:27 <mtreinish> #topic Specs Reviews
17:09:40 <mtreinish> does anyone have, any open specs to bring up
17:09:55 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
17:10:18 <mtreinish> doesn't look like there is much activity in specs right now, I expect that'll probably pick up again around summit
17:10:56 <mtreinish> #topic Tempest
17:11:10 <mtreinish> ok, does anyone have anything to discuss about tempest today?
17:11:14 <mtreinish> open bps, etc?
17:11:35 <dpaterson> test accounts.
17:11:48 <mtreinish> dpaterson: oh, that's a good one. I actually have an update on that :)
17:11:56 <mtreinish> dpaterson: but you go first
17:12:11 <dpaterson> I have had no luck running complete suite with test accounts.  Hangs do to locking error.
17:12:20 <dpaterson> Don't have a lot of detail at m
17:12:42 <dpaterson> Has anyone had luck running with test accounts?
17:12:55 <mtreinish> dpaterson: yes, that was my update :)
17:12:56 <mtreinish> https://review.openstack.org/#/c/211601/
17:13:14 <mtreinish> that has the new experimental/periodic test-accounts job running on it
17:13:27 <mtreinish> I've been working on adding those so we can land the deprecation patch
17:13:48 <mtreinish> right now there is a bug with 1 neutron test and the generator script which are blocking it from working
17:14:15 <mtreinish> but for example:
17:14:17 <mtreinish> #link http://logs.openstack.org/01/211601/8/experimental/gate-tempest-dsvm-full-non-isolated/e9f4993/
17:14:25 <mtreinish> that is successfully running with n-net and test-accounts
17:14:47 <dpaterson> perhaps my problem was on neutron
17:15:12 <mtreinish> dpaterson: well, the neutron failure is a single test that fails, but otherwise it works
17:15:33 <mtreinish> dpaterson: we can take this up on -qa after the meeting and I can help you go through your setup
17:15:39 <dpaterson> mtreinish: sure
17:16:26 <mtreinish> does anyone else have any thing else to discuss on tempest?
17:17:06 <jordanP> nope, we made good progress on the unit tests side
17:17:18 <jordanP> for the clients
17:18:06 <mtreinish> jordanP: oh, cool. Do you know if we're ready to start the actual migration of some clients to tempest-lib soon?
17:18:22 <mtreinish> because fwiw, I think we can always add unit tests after the migration too
17:19:06 <jordanP> yeah but the current pace is good, so maybe we should wait until we do the move
17:19:43 <mtreinish> jordanP: ok sure, I'm fine with not blocking the pace
17:20:04 <mtreinish> I was only just bringing it up because the clients living in the lib has been a big thing for a while
17:20:12 <mtreinish> so I'm anxious to get it :)
17:20:45 <jordanP> yeah, me too. Plus we see more and more project having funct tests in there tree, so this is needed
17:20:53 <jordanP> *their
17:21:33 <mtreinish> ok, anything else? otherwise let's move on
17:22:59 <mtreinish> #topic Devstack
17:23:12 * sdague sneaks in
17:23:16 <mtreinish> ok there are a couple of topics in the agenda from jamielennox and rcrit on the agenda
17:23:32 <sdague> cdent has patches up to pull ceilometer into a plugin
17:23:45 <mtreinish> sdague: awesome
17:24:05 <sdague> so, yeh, the tls patches
17:24:34 <mtreinish> rcrit: still around?
17:24:37 <rcrit> yeah
17:24:45 <rcrit> so it is really broader than tls, that's just where I ran into it
17:24:59 <mtreinish> sdague: fwiw, I tend to agree with you this just seems like something the service catalog should be doing
17:25:02 <rcrit> the issue is if there is a proxy in front of a service then one needs to set a config option to tell that service what the proxy value is
17:26:05 <rcrit> so while I don't disagree that this is less than ideal, it's how things currently work, and it is blocking having tls proxy be part of the gate
17:26:17 <rcrit> which inevitably leads to breakage every few weeks
17:27:00 <sdague> here is my concern, reiterated, we slap this in. Then everyone disappears when we need help fixing the real issue.
17:27:15 <rcrit> so use devstack as a wedge?
17:27:32 <sdague> devstack has often been that wedge of sane integration between components
17:27:39 <sdague> because it's where all the pain gets felt
17:27:43 <sdague> for better or worse
17:29:10 <rcrit> so it's a balance of how badly one wants tls testing done vs forcing the services to do the right thing
17:29:51 <mtreinish> rcrit: I think all we're saying is that before we land something like this there has to be at least a plan in place and work being done to start correcting the issue
17:29:53 <sdague> right, and what I said is that I really wanted a plan of how we get to the good place, before we do this work around.
17:30:22 <rcrit> well, I'm just a lowly guy trying to add tls, I'm not the one to come up with this plan
17:30:50 <sdague> ok, so lets identify who is.
17:31:15 <sdague> the service catalog is part of keystone, so it seems like keystone folks should own some of the responsibility here
17:31:43 <rcrit> I think they would argue that the catalog is there for the using
17:31:57 <rcrit> despite the fact that they themselves do the same bad practice
17:32:11 <rcrit> but perhaps if they show how it's done, it might be consumable by others?
17:32:26 <sdague> so, this is the reason I'm going to keep -1ing this patch. Because we keep going around in circles on excuses to not fix this.
17:33:22 <rcrit> I wasn't excusing it, just pointing out the obvious
17:33:38 <rcrit> I imagine this code has been cut-and-pasted with each new service
17:33:51 <rcrit> so if one fixes it the others will probably be able to again copy it
17:33:52 <sdague> sure, it has, but we draw the line eventually when folks do that
17:34:03 <sdague> it was the whole reason oslo was created, for instance
17:34:17 <sdague> so deciding "enough is enough" is not a new thing in OpenStack
17:35:14 <rcrit> so to reiterate, the plan is to have keystone fix it first?
17:35:21 <rcrit> and then the other services follow their model?
17:35:32 <sdague> what I'd be comfortable with
17:36:07 <sdague> 1) a plan on how we get to a good place where we don't need these config vars at all - agreed to by keystone folks
17:36:11 <sdague> 2) workaround gets landed
17:36:15 <sdague> 3) work towards real plan
17:36:43 <sdague> I get that fixing the world is going to take a while, but I want to see a plan on how we'd do that emerge before landing the work around
17:36:58 <rcrit> you lost me on the workaround bit
17:37:06 <sdague> your patch is the work around
17:37:20 <sdague> where we set all the manual configs for all the services
17:38:02 <rcrit> so we need to get morgan, jamie and others to agree to this?
17:38:32 <mtreinish> sdague, rcrit: in the interest of time, can you guys continue the discussion in -qa or -keystone?
17:38:37 <sdague> sure
17:38:54 <mtreinish> great thanks
17:38:54 <sdague> though I feel like it's mostly a reiteration of the -qa conversation the other day
17:39:19 <mtreinish> sdague: heh, it might be. I missed that conversation
17:39:38 <rcrit> well, you keep saying you want a plan but haven't really expanded on what that meant until today IMHO
17:39:49 <sdague> rcrit: ok, sorry, I thought it was clear
17:39:58 <mtreinish> anyway, let's move on
17:40:00 <mtreinish> #topic Grenade
17:40:22 <mtreinish> so I guess the big news this week is cdent landing the ceilo grenade plugin stuff
17:40:31 <sdague> yeh, I think that's the only big notable
17:40:31 <mtreinish> which is awesome
17:40:41 <cdent> does that actually count as a big deal?
17:40:56 <cdent> if so: go me! :)
17:41:13 <mtreinish> #info ceilometer grenade plugin migration counts as a big deal
17:41:16 <mtreinish> :)
17:41:18 <sdague> :)
17:41:22 <cdent> ha!
17:41:27 <morgan> rcrit: you need to catch me up on the patch in question post meeting
17:41:50 <mtreinish> ok, does anyone else have something on grenade to discuss?
17:41:51 <morgan> Cc sdague ^
17:42:01 * morgan goes back to lurking
17:42:16 <mtreinish> morgan: where's the grenade discussion point?
17:42:33 <morgan> This was above. I was slow to type mobile
17:42:41 <morgan> Before you switched topics.
17:42:44 <mtreinish> hehe, just giving you a hard time :)
17:43:01 <mtreinish> anyway, let's move on
17:43:05 <morgan> ^_^
17:43:14 <mtreinish> #topic Adding StackViz to QA (timothyb89 / austin81)
17:43:22 <mtreinish> timothyb89, austin81: still around?
17:43:26 <austin81> yep
17:43:30 <timothyb89> yup
17:43:52 <mtreinish> cool, so why not give like a 2 sentence summary of what stackviz is
17:44:08 <mtreinish> and maybe a link to it somewhere
17:44:36 <timothyb89> stackviz is a utility to view performance and debugging info for runs of devstack and tempest
17:45:05 <timothyb89> code is current at https://github.com/timothyb89/stackviz and an example is running at  http://15.126.244.104:8080/tempest_timeline_file_testrepository.subunit_0.html
17:45:16 <mtreinish> #link http://15.126.244.104:8080/tempest_timeline_file_testrepository.subunit_0.html
17:45:31 <mtreinish> #link https://github.com/timothyb89/stackviz
17:45:34 <jordanP> looks nice !
17:46:00 <sdague> oh, super nice
17:46:30 <austin81> the aim is to make debugging devstack/tempest runs a little more intuitive and eventually apply this knowledge to improving runtimes across the board
17:47:10 <sdague> yeh, the timeline is awesome.
17:47:54 <jordanP> how could we make this tool more "available" ?
17:47:57 <austin81> In the future we plan to integrate the timeline in analysis of upstream runs as well (via subunit2sql mainly)
17:47:58 <sdague> so, can you break out some of the memory types in the mem section. Because cached vs. used would be good
17:48:25 <austin81> sdague: absolutley yeah that would be helpful
17:48:28 <timothyb89> sdague: certainly, we do have all of that data available, presentation is a bit rough at the moment
17:48:41 <sdague> but, overall, this is super nice
17:48:53 <timothyb89> jordanP: we have a patch to run it during devstack-gate cleanup: https://review.openstack.org/#/c/212207/
17:48:59 <sdague> would be great to be just in the log dir generated after a run
17:49:19 <mtreinish> #link https://review.openstack.org/#/c/212207/
17:49:29 <austin81> jordanP: Correct me if I'm wrong, timothyb89, but I believe there was talk of setting up a small puppet module for a server?
17:49:37 <timothyb89> sdague: in fact it is! http://logs.openstack.org/07/212207/4/check/gate-tempest-dsvm-full/5a812af/logs/stackviz/
17:49:44 <sdague> ok, so strackviz needs to go into openstack proper first, right?
17:49:56 <sdague> then we can retool 212207 for landing
17:50:01 <timothyb89> sdague: yes, that is our intention
17:50:20 <sdague> cool
17:50:27 <sdague> awesome, great stuff
17:50:31 <mtreinish> sdague: yep, which I think what this topic was for, the qa project adoption
17:50:42 <mtreinish> which I'm +1 on, I'll go add that to the reviews
17:50:48 <timothyb89> austin81: yes, though we will need to hash out some details with testr integration
17:51:27 <mtreinish> ok cool, does anyone have anything else on this topic?
17:51:46 <mtreinish> #action QA to adopt stackviz project
17:52:03 <mtreinish> err or should that be info? whatever
17:52:38 <mtreinish> #topic Critical Reviews
17:52:52 <mtreinish> does anyone have any open reviews they'd like to get extra eyes on?
17:53:27 <mtreinish> I've got a couple this week:
17:53:28 <mtreinish> #link https://review.openstack.org/#/c/216522/
17:53:34 <mtreinish> which is just a maint thing
17:53:45 <mtreinish> err got that backwards
17:53:51 <mtreinish> that's the one which needs discussion
17:53:57 <mtreinish> #link https://review.openstack.org/#/c/216438/
17:54:01 <mtreinish> that's the general main one
17:54:25 <mtreinish> just switching to using an oslo lib
17:55:01 <mtreinish> #link https://review.openstack.org/#/c/216386/
17:55:07 <mtreinish> and a docs improvment
17:55:25 <mtreinish> I think that's all from me
17:55:31 <mtreinish> does anyone else have any reviews to bring up?
17:55:38 <hichihara> My patches need devstack core's reviews https://review.openstack.org/#/c/204951/ https://review.openstack.org/#/c/204956/ https://review.openstack.org/#/c/204965/
17:55:52 <hichihara> These patches remove dependence of vendor plugin.
17:56:18 <hichihara> Some vendor codes are unnecessary in neutron_plugins but they are left by the dependence.
17:56:22 <mtreinish> #link https://review.openstack.org/#/c/204965/
17:56:28 <mtreinish> #link https://review.openstack.org/#/c/204956/
17:56:35 <mtreinish> #link https://review.openstack.org/#/c/204951/
17:56:47 <hichihara> Thanks. If this is merged, we will be able to remove their codes from neutron_plugins.
17:56:47 <mtreinish> hichihara: ok, cool. I'll try to take a look after lunch
17:57:09 <hichihara> mtreinish: Thank you :)
17:57:32 <mtreinish> are there any other reviews? otherwise I guess we'll end here for today
17:58:06 <mtreinish> oh, before I forget if you're planning on coming to the qa code sprint can you throw your name on the wiki:
17:58:09 <mtreinish> #link https://wiki.openstack.org/wiki/QA/CodeSprintLibertyFortCollins
17:58:57 <mtreinish> thanks everyone
17:59:01 <mtreinish> #endmeeting