17:06:18 <mtreinish> #startmeeting qa
17:06:19 <openstack> Meeting started Thu Jul 30 17:06:18 2015 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:20 <mtreinish> oops
17:06:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:06:24 <openstack> The meeting name has been set to 'qa'
17:06:26 <mtreinish> sry, I lost track of time
17:06:29 <mtreinish> who's here today?
17:06:36 <dpaterson> o/
17:06:40 <jordanP> o/
17:06:42 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_July_30th_2015_.281700_UTC.29
17:06:45 <mtreinish> ^^^ today's agenda
17:07:32 <mtreinish> dkranz, sdague: around?
17:07:41 <dkranz> o/
17:07:59 <mtreinish> ok, let's get started
17:08:09 <mtreinish> #topic Specs Reviews
17:08:17 <mtreinish> Does anyone have any open specs reviews to discuss today?
17:08:23 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
17:09:24 <dkranz> mtreinish: https://review.openstack.org/94473
17:09:34 <dkranz> mtreinish: we should really decide what to do with this
17:09:41 <dkranz> config_tempest
17:10:02 <mtreinish> well, I thought you had a POC whatever happened to that?
17:10:05 <dkranz> I am going to be adding test-accounts and configuring as non-admin
17:10:16 <dkranz> mtreinish: Yes, it is still there, and improving
17:10:37 <dkranz> mtreinish: But I don't think we have defined what needs to be done for it to be accepted
17:11:00 <mtreinish> dkranz: ok, well the thing with that spec is it hasn't seen an update since Dec. and there wasn't agreement there
17:11:09 <dpaterson> dkranz: is your script to be used as a jumpstart to implement bp?
17:11:25 <mtreinish> dkranz: do you want to take a new wack at a spec (either take that over or a new patch) based on your script
17:11:38 <mtreinish> s/wack/whack/
17:11:50 <dkranz> mtreinish: I will do that, and add the non-admin/test-accounts stuff
17:12:08 <mtreinish> dkranz: ok cool
17:13:06 <mtreinish> ok are there any other specs to discuss?
17:14:09 <mtreinish> I guess not, then let's move on
17:14:17 <mtreinish> #topic Blueprints
17:14:31 <mtreinish> does anyone have an in progress bp to discuss
17:14:34 <mtreinish> or give an update on?
17:15:35 <mtreinish> well I wanted to discuss the tempest external plugin one
17:16:03 <mtreinish> there are 2 patches up right now, one for the last interface I think we need and one for docs
17:16:14 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/external-plugin-interface,n,z
17:16:36 <mtreinish> once those land all that we need in the tempest tree are some basic unit tests to cover things
17:17:02 <mtreinish> mkoderer: is still working on the manila side I think
17:17:21 <mtreinish> but once that's working (and running in the gate) I'll take it to the ML
17:17:57 <mtreinish> I'm wondering if after the doc patches lands whether this warrants a tag or not?
17:18:21 <jordanP> I am reading this, but I have no idea :)
17:19:28 <mtreinish> jordanP: heh, ok
17:20:04 <mtreinish> we've always said we'd push additional tags for dev milestones in tempest, but we've only done it once which was for the removal of xml testing
17:20:39 <mtreinish> so I was just wondering if we want to plan to push tempest-6 for the plugin interface when we close the bp
17:20:42 <dpaterson> mtreinish: is a sample plugin implementation included?
17:20:45 <dkranz> mtreinish: we did say this but seems like it is really only needed for major *removals*
17:20:55 <mtreinish> or we can wait until the end of the cycle
17:20:55 <dkranz> mtreinish: but it could not hurt either
17:21:04 <jordanP> exaclty, "removal"
17:21:06 <mtreinish> dkranz: yeah it doesn't really matter one way or the other I guess
17:21:26 <mtreinish> dpaterson: well we're using manila as an example, mkoderer is working on that
17:21:48 <mtreinish> I'm fine with saying just for major removals
17:22:02 <dpaterson> mtreinish: seems a tag would be good if the feature is considered complete
17:22:05 <mtreinish> which the plugin interface will likely prompt :)
17:22:09 <mrodden> its good to version your interfaces in general... but i wouldn't tag until you know someone needs it
17:22:44 <mtreinish> mrodden: that's a good point
17:22:49 <mrodden> i.e. until someone is using the interface basically
17:23:01 <mtreinish> yeah, right now there is no one
17:23:06 <mtreinish> it's in progress
17:23:14 <mtreinish> well, we can discuss it again when things are more complete
17:23:18 <dpaterson> so when manila is done tag it perhaps?
17:23:18 <mtreinish> it was just something I was thinking about
17:23:38 <mtreinish> dpaterson: sure that probably makes sense
17:24:00 <mtreinish> ok are there any other bps to discuss?
17:24:02 <mrodden> that makes sense to me.
17:25:05 <mtreinish> #topic Tempest sample config check job (mtreinish)
17:25:14 <mtreinish> so this was something I wanted to talk about briefly
17:25:30 <mtreinish> I'm sure people have noticed that basically every week oslo has been pushing releases now
17:25:42 <mtreinish> which when they include config changes breaks our sample check job
17:25:49 <mtreinish> causing a gate backup until we fix it
17:26:09 <mtreinish> I pushed up a patch to stop gating on config options in oslo here:
17:26:11 <mtreinish> #link https://review.openstack.org/206227
17:26:29 <mtreinish> the tradeoff there is that we need options for some oslo libs to make tempest work
17:26:44 <mtreinish> so I leveraged tempest init to generate a new sample config on the fly using oslo libs too
17:27:09 <mtreinish> I just wanted to discuss the approach and see if people were ok with an in-tree sample thats missing the oslo opts
17:27:27 <jordanP> this means the issuing "tempest init" will be required ?
17:27:35 <jordanP> s/the/that/
17:28:05 <mtreinish> not really, you can still do things out of the tree, but if you do cp tempest.conf.sample tempest.conf
17:28:13 <mtreinish> you'll have to know to add the oslo opts manually
17:28:17 <mtreinish> since they won't be there
17:28:44 <mtreinish> although tempest init will make it easier
17:29:04 <dpaterson> mtreinish should tempest.conf.sample be depricated in favor if generating on init always/
17:29:19 <jordanP> how are other projects dealing with that ? (oslo config changes)
17:29:33 <dkranz> jordanP: many projects stopped generating sample conf
17:29:35 <mtreinish> jordanP: most projects have dropped in tree sample files because of the oslo thing
17:29:41 <jordanP> ok
17:30:02 <dkranz> jordanP: they just tell you to run 'tox -egenconfig' basically
17:30:06 <jordanP> then I agree with dpaterson then.
17:30:14 <mtreinish> dpaterson: well, I thought the user feedback was that there was value for having an in tree file
17:30:26 <dkranz> mtreinish: There is!
17:30:27 <jordanP> I don't think providing a broken sample config is a good approach
17:30:41 <dpaterson> but if it's always out of sync not super helpful
17:30:49 <dkranz> mtreinish: but users don't have to deal with keeping up with the breakage
17:31:03 <dkranz> out of sync, but there, is not an option IMO
17:31:09 <mrodden> i like the idea of tempest init generate it
17:31:26 <mrodden> also i think maybe the requirement is having an updated posted somewhere?
17:31:33 <mrodden> so maybe generate one with the docs?
17:31:46 <mrodden> an up-to-date sample posted somewhere*
17:31:48 <mtreinish> mrodden: yeah that's what my other thought was make it part of the docs publish post job
17:31:56 <dkranz> mrodden: ++
17:32:11 <mtreinish> I'm not sure how hard that would be
17:32:17 <mtreinish> does someone want to investigate it?
17:32:33 <mrodden> yeah might be a sphinx plugin at worst
17:33:00 <mrodden> i can see if i can look into it
17:33:09 <mtreinish> mrodden: ok, cool thanks
17:33:19 <mtreinish> #action mrodden to look into getting sample configs in docs
17:33:52 <mtreinish> ok, was there anything else to discuss on this?
17:33:58 <jordanP> so it means with are deprecating the sample config in tree ?
17:33:59 <mtreinish> are people ok with my patch in the short term
17:34:28 <mtreinish> jordanP: yeah, I think that's what we're moving towards
17:34:46 <mtreinish> so we wont have it in tree when we have a doc publish option
17:36:05 <jordanP> mtreinish, with your patch, the sample config will be incomplete ou plain broken ?
17:36:29 <dkranz> jordanP: incomplete, missing oslo
17:36:39 <mtreinish> yeah, just incomplete
17:37:05 <mtreinish> well, in the interest of time I think we need to move on
17:37:12 <jordanP> yup
17:37:23 <mtreinish> I'll bring this up on the ML to get some wider opinions on this
17:37:36 <mtreinish> #topic Devstack
17:37:52 <mtreinish> does anyone have anything to discuss on devstack this week?
17:37:57 <mtreinish> I don't think dtroyer is around
17:38:31 <mtreinish> I did want to bring up this patch:
17:38:33 <mtreinish> #link https://review.openstack.org/207247
17:38:44 <mtreinish> which was something we forgot to do at the kilo release
17:38:49 <mtreinish> luckily it hasn't come up :)
17:39:51 <mtreinish> ok, well if there isn't anything else lets move on
17:40:17 <mtreinish> #topic Grenade
17:40:20 <jordanP> I thing the patch is good :)
17:40:42 <jordanP> (required)
17:40:43 <mtreinish> jordanP: heh, thanks
17:41:03 <mtreinish> does anyone have anything to discuss on grenade this week?
17:41:09 <mtreinish> sdague: ^^^ ?
17:42:29 <mtreinish> ok, I guess not :)
17:42:56 <mtreinish> #topic Critical Reviews
17:43:24 <mtreinish> does anyone have any reviews they'd like to get additional eyes on?
17:43:32 <dkranz> mtreinish: https://review.openstack.org/206643 will clear one of the two failing periodic jobs
17:43:45 <mtreinish> #link https://review.openstack.org/#/c/206643/
17:43:50 <dkranz> Already has a +2
17:44:56 <dkranz> dpaterson: your cleanup patch needs a rebase but would be really good to get that in
17:45:04 <dpaterson> Yup
17:45:32 <dpaterson> Got hammered this week trying to rebase and fix today with luck
17:45:38 <dkranz> #link https://review.openstack.org/#/c/204230/
17:46:03 <mtreinish> ok, yeah I'll try to take a look at that again
17:46:09 <mtreinish> thanks for splitting up per my suggestion
17:46:21 <Luz_> nice :-)
17:46:25 <dpaterson> this one would be good to get merged: #link https://review.openstack.org/#/c/203876/
17:47:09 <jordanP> it's not critical at all (the oposite): what about the patch series that adds unit tests to clients ? I don't see a lot of value in those, but they don"t hurt either...
17:47:20 <dpaterson> mtreinish, https://review.openstack.org/#/c/203876/ is another part of the split, neutron related only
17:47:39 <dkranz> jordanP: I had some issues with the way that is being done and what the intent is
17:47:46 <mtreinish> dpaterson: ok, yeah I'll review that soon
17:47:54 <dkranz> jordanP: the code to value ratio seems quite low
17:48:11 <jordanP> dkranz, yeah I saw your comment. I kinda agree with you... it's a lot of work for the guy, and also to review
17:48:29 <mtreinish> dkranz, jordanP: well I think have some coverage for the clients is something we'll need for when it's in the lib
17:48:50 <mtreinish> because there are actually a lot of py3 bugs in the clients
17:49:08 <mtreinish> but I agree I don't think how that's being done is ideal necessarily
17:49:22 <dkranz> mtreinish: maybe there should be a spec for this?
17:49:37 <mtreinish> dkranz: heh, there are already like 2-3 specs for the client migration :)
17:49:46 <dkranz> mtreinish: so we can come to an approach before reviewing a zillion patches
17:50:04 <jordanP> I am not sure we need to write a spec to add some unit tests...
17:50:22 <mtreinish> jordanP: yeah, that's what I'm thinking. A spec is a bit heavyweight
17:50:39 <jordanP> what bother me most is that we have a lot of very small patch, i'd rather those patches were squashed...
17:50:40 <mtreinish> I think if we just talk to the contributor we can figure somethign out
17:50:46 <dkranz> mtreinish: sure
17:50:51 <mtreinish> I think he works closely with oomichi too
17:51:07 <mtreinish> jordanP: yeah a patch per method is a bit much :)
17:51:32 <jordanP> okay. I'll ask for bigger patch next time
17:52:00 <jordanP> the other thing I'd like to discuss is the **kwargs patch series
17:52:16 <dkranz> I'm not bothered by unit tests which are good. Just seems they all have the same code which should be abstracted somehow.
17:52:46 <dkranz> jordanP: I had mixed feelings about that which happened while I was away
17:52:52 <mtreinish> dkranz: yeah having a common util method to do the tests will help
17:53:02 <jordanP> dkranz, then -1 them and leave a comment
17:53:12 <jordanP> (the unit test patches)
17:53:13 <mtreinish> dkranz, jordanP it's on the ML, I don't think it's a final decision
17:53:24 <dkranz> jordanP: I left the comment, just without the -1 :)
17:53:32 <jordanP> mtreinish, so let's wait ?
17:53:54 <dkranz> mtreinish: I didn't see you weigh in on it, did I miss it?
17:53:57 <mtreinish> jordanP: well, if you have concerns about the approach I'd say respond to oomichi's ML thread about it
17:54:17 <mtreinish> dkranz: heh, I forgot to respond to it :)
17:54:23 * mtreinish is really a slacker
17:54:45 <dkranz> It's a tough call IMO
17:54:53 <jordanP> no, no concern, to me it makes no difference (kwargs or the previous way)
17:55:20 <mtreinish> although I'm generally in favor of allowing kwargs, because I think it makes thing a bit more future proof
17:55:45 <mtreinish> but I haven't really reviewed those patches
17:56:02 <mtreinish> anyway lets take this to the ML or the reviews
17:56:19 <mtreinish> I'll try to remember to respond there too :)
17:56:26 <mtreinish> #topic Open Discussion
17:56:49 <mtreinish> So I wanted to briefly talk about our midcycle (really end of cycle sprint)
17:57:13 <mtreinish> I have a room reserved in ft collins from Sept. 9th-11th
17:57:34 <mtreinish> but it was raised that it's a holiday week and somethings close on 9/11 in the US
17:57:40 <mtreinish> so I can push it back a week
17:57:53 <mtreinish> I wanted to see if people had opinions before I made a ML announcement about it
17:59:49 <mtreinish> well we've got ~1min left so let's pick this up in -qa
17:59:56 <mtreinish> thanks everyone
18:00:04 <mtreinish> #endmeeting