22:00:39 <mtreinish> #startmeeting qa
22:00:40 <openstack> Meeting started Thu Dec 11 22:00:39 2014 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:43 <openstack> The meeting name has been set to 'qa'
22:00:44 <mtreinish> hi, who's here today?
22:01:03 <Rockyg> o/
22:01:04 <dmorita> Hi
22:01:06 <oomichi> hi!
22:01:10 <masayukig> \o
22:01:10 <gmann> hi
22:01:18 <marun> hi
22:01:24 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_December_11th_2014_.282200_UTC.29
22:01:27 <mtreinish> ^^^ today's agenda
22:01:44 <mtreinish> dkranz, dtroyer, sdague: around?
22:01:56 <dkranz> mtreinish: here
22:02:09 <mtreinish> ok, well let's get started
22:02:19 <dtroyer> o/
22:02:22 <mtreinish> #topic Spec Reviews
22:02:35 <mtreinish> does anyone have an open spec review to bring up?
22:02:58 <mtreinish> andreaf: asked me to mention:
22:03:00 <mtreinish> #link https://review.openstack.org/#/c/94741/
22:03:16 <mtreinish> but I think that's waiting on me, so I'll take a look at it tomorrow morning :)
22:03:41 <mtreinish> are there any other spec reviews to bring up?
22:04:14 <oomichi> one thing
22:04:47 <oomichi> can we implement tempest-lib feature based on the approved tempest-lib spec?
22:05:29 <mtreinish> oomichi: yeah, I assume you're asking about the rest client migration. I think that's fine to go forward against the existing spec
22:06:09 <oomichi> yes, right. I am asking for rest client thing. and OK, i got it. thanks!
22:06:40 <dkranz> mtreinish: are we all good with removing nova v3? I was ready to do it months ago.
22:06:42 <mtreinish> oomichi: unless you wanted to write a more detailed spec before. I'll leave it up to you :)
22:06:58 <mtreinish> dkranz: yeah I think that's fine. oomichi you posted a patch for that right?
22:07:07 <mtreinish> dkranz: we haven't been running it for quite some time
22:07:11 <dkranz> mtreinish: yes, that is why I was putting it out there
22:07:30 <dkranz> git clone will be even faster
22:07:45 <oomichi> right, and I'd like to write the detail on the spec more for the dev scope.
22:08:15 <mtreinish> oomichi: is that?: https://review.openstack.org/#/c/140608/
22:08:45 <oomichi> yes, right. but it is very small now ;)
22:09:08 <oomichi> and I will write the interfaces of the lib.
22:09:35 <oomichi> but before that, much cleanup seems necessary for knowing what is necessary interfaces.
22:10:05 <oomichi> and I am doing cleanup.
22:10:09 <mtreinish> oomichi: yeah, I agree, there are a bunch of cleanups needed first. (it's some of the oldest code in tempest)
22:10:37 <oomichi> mtreinish: thanks:)
22:11:01 <mtreinish> ok is there anything else on the rest client migration or any other specs?
22:11:07 <mtreinish> otherwise let's move on
22:12:06 <mtreinish> #topic Blueprints
22:12:22 <mtreinish> #link https://blueprints.launchpad.net/tempest/
22:12:35 <mtreinish> are there any open bps that anyone would like to discuss
22:12:39 <mtreinish> or give a status update on?
22:12:58 <gmann> mtreinish: cinder v2 testing BP is completed. last patch is merged.
22:13:07 <gmann> #link https://blueprints.launchpad.net/tempest/+spec/cinder-v2-api-tests
22:13:17 <mtreinish> gmann: ok cool, do you want to mark that as completed on lp
22:13:26 <mtreinish> and then I'll approve the spec move patch
22:13:41 <gmann> Yes, Thanks
22:14:03 <mtreinish> for the branchless tempest extensions I've pushed forward a bit
22:14:07 <mtreinish> #link https://blueprints.launchpad.net/tempest/+spec/branchless-tempest-extensions
22:14:20 <mtreinish> I landed stable devstack patches hard coding the extension list
22:14:56 <mtreinish> and I fixed up salv-orlando's master patch which adds support to disable extensions dynamically, (if needed) but by default it still uses all
22:15:12 <mtreinish> I think that was approved too
22:15:49 <oomichi> is that for neutron?
22:16:01 <mtreinish> all that's left is to add d-g support to override the devstack defaults
22:16:11 <mtreinish> oomichi: all projects we have a tempest api_extensions opt for
22:16:19 <mtreinish> so nova, cinder, neutron, and swift
22:16:30 <oomichi> ah, I see.
22:16:53 <mtreinish> I'm thinking I might change the devstack side to always be a complete list, because the dynamic depends on an api poll, which I'm not really comfortable with
22:17:07 <mtreinish> but I'm not sure
22:18:03 <mtreinish> oomichi: https://review.openstack.org/140078 , https://review.openstack.org/140090 , and https://review.openstack.org/126422
22:18:33 <oomichi> mtreinish: thanks, and I am reading original spec.
22:18:36 <mtreinish> once salv-orlando fixes up his d-g side fix and that lands I think we'll be good to close that bp finally
22:18:47 <mtreinish> are there any other bps to discuss?
22:19:57 <mtreinish> ok, then let's move on
22:20:14 <mtreinish> #topic Proposed plan for moving neutron rest client to tempest lib (dkranz)
22:20:18 <mtreinish> dkranz: you're up
22:20:30 <mtreinish> although I'm not sure why you didn't just write a spec first... :)
22:20:49 <dkranz> mtreinish: Well, it is not just a qa-spec
22:21:02 <dkranz> mtreinish: I wanted to discuss this and was putting a stake in the ground
22:21:22 <dkranz> mtreinish: I have a patch for the neutron client changes up https://review.openstack.org/#/c/141152/
22:21:44 <dkranz> mtreinish: does any one have any issues with the little plan I put in the agenda? marun ?
22:21:55 <mtreinish> dkranz: I'm fine with that plan, the only thing I don't like about it is using neutron as an incubator for the tempest-lib migration
22:22:09 <dkranz> mtreinish: why not?
22:22:18 <marun> mtreinish: the thought is that we need to get the neutron api job gating
22:22:37 <marun> mtreinish: and we can't do that so long as tempest is not gating on the neutron api job
22:22:51 <mtreinish> I'd rather see us get what's in tempest migrated to tempest-lib as a replacement for what we have, and then iterate on it there if things need to be fixed for outside consumers
22:23:02 <mtreinish> otherwise we end up with a lot of dual code maintanence
22:23:22 <marun> mtreinish: we're willing to accept that burden as a way of ensuring that new test development can happen in neutron
22:23:22 <mtreinish> I'd rather just have one copy lying around
22:23:38 <dkranz> mtreinish: I thought that was what I was proposing, except for a short time period
22:23:55 <marun> mtreinish: otherwise, what kind of timeline are we looking at for the client to be consumable?  this is a stop-gap, and if the timeline is short enough then maybe it's worth waiting
22:24:43 <mtreinish> marun: well oomichi is making good progress on the rest client library modifications
22:24:56 <marun> mtreinish: a week?  a month?
22:25:00 <mtreinish> so I think that should be pretty soon
22:25:04 <mtreinish> oomichi: ^^^ ?
22:25:06 <marun> mtreinish: as I said, this isn't intended to burden the qa team.
22:25:21 <marun> mtreinish: the neutron side of things would maintain the client until tempest-lib became an option
22:25:25 <marun> (in-tree I mean)
22:25:27 <oomichi> yeah, maybe one month.
22:25:32 <mtreinish> marun: I view having multiple copies as more of a burden
22:25:44 <marun> mtreinish: Why is it a problem if it's not on your team?
22:25:51 <dkranz> mtreinish: My thought was to solidify the code inside tempest first.
22:26:18 <dkranz> mtreinish: And then it can be used temporarily without waiting for the actual migration which will take some time
22:26:20 <marun> mtreinish: we wouldn't be changing the code in-tree.  At most we'd copy from tempest/tempest-lib until tempest-lib became consumable.
22:26:30 <dkranz> mtreinish: exactly
22:26:31 <marun> mtreinish: oslo-incubator style
22:27:03 <mtreinish> marun: that's what I'm trying to avoid, because if we have 2 copies lying around we have to block dev on 1 otherwise things will diverge
22:27:15 <dkranz> mtreinish: the only in-tree changes would be those that are moving towards the code going into tempest-lib
22:27:15 <marun> mtreinish: we don't have to block anything
22:27:26 <marun> mtreinish: the intent is not for the neutron copy to diverge
22:27:28 <mtreinish> and blocking dev on the restclient in tempest lib while we try to migrate it seems counter productive
22:27:30 <marun> mtreinish: it's write-once
22:27:38 <dkranz> mtreinish: the only major work planned in the neutron client is the patch I just put up
22:28:04 <dkranz> mtreinish: Adding tests to neutron does not impact this at all
22:28:13 <mtreinish> marun: that's not what the agend says in the 4th bullet
22:28:18 <dkranz> mtreinish: so I am not sure what you mean by blocking anything
22:29:02 <mtreinish> dkranz: if there are 2 copies of the same code lying around and people are working on both, things always diverge.
22:29:05 <marun> mtreinish: I'm guessing the intention was to modify the client in tempest if we discovered changes that needed to be made.
22:29:12 <dkranz> mtreinish: that item was referring to the possibility that we could find out that using the tempest-lib version had an issue we did not think of
22:29:14 <marun> mtreinish: Rather than make any changes in the neutron tree.
22:29:31 <marun> mtreinish: so 'copying' is really just bad wording
22:29:54 <mtreinish> this is why I thought a spec would have been good... :)
22:30:08 <marun> mtreinish: you have my word that we won't modify any copied tempest code in the neutron tree.
22:30:13 <mtreinish> marun: if you want to copy the code pre-libification I guess go ahead, but there is the risk of things changing
22:30:24 <mtreinish> even if it's unlikely
22:30:42 <marun> mtreinish: we understand the risk, no worries. it's worth bearing if we can start moving/writing api tests in the neutron tree by having the api job gate.
22:30:43 <mtreinish> you could also just import tempest, which is what some other projects do (I'm not sure which is the lesser of 2 evils)
22:30:55 <marun> mtreinish: we can't gate so long as we import tempest, though.
22:31:02 <marun> mtreinish: unless tempest gates on us too.
22:31:13 <dkranz> mtreinish: importing tempest has the risk that a non-gated change happens out from under you
22:31:28 <mtreinish> dkranz: but that's the same risk as the api diverging from what's copied
22:31:30 <marun> mtreinish: would you be willing to start gating on the neutron api job once we get it running?
22:31:58 <dkranz> mtreinish: anyway, the reason I didn't write a spec is that this is not about changes to tempest. There is not change to what we are doing with tempest as a result of this discussion.
22:31:59 <marun> mtreinish: if so, we could continue to import rather than resorting to copying.
22:32:05 <mtreinish> marun: not really, considering how many dsvm jobs are on tempest already. I wasn't saying it's better, just what others have been doing while waiting for the lib to finish
22:32:08 <dkranz> mtreinish: It is about coordinating the activities of two teams
22:32:26 <marun> mtreinish: We definitely don't want to wait a month, so given the choice we'd prefer to copy.
22:33:09 <dkranz> Anyway, that's all I had about this.
22:33:25 <marun> mtreinish: Then we ensure that development of new neutron api tests can happen directly in the neutron tree rather than having to be written once and then ported.
22:33:38 <marun> mtreinish: that's it from me too.
22:33:48 <mtreinish> marun: sure I understood the goal
22:34:08 <mtreinish> I just had some concerns with copy and pasting code, based on the agenda
22:34:19 <mtreinish> but I think this is fine based on the discussion
22:34:24 <mtreinish> ok, does anyone have anything else to add on this?
22:34:57 <mtreinish> ok, let's move on
22:35:01 <mtreinish> #topic Devstack
22:35:11 <dkranz> mtreinish: seems to be major lossage in the gate now
22:35:14 <dkranz> Endpoint type data_processing is available, service sahara should be set as available in the config file.
22:35:14 <dkranz> 2014-12-11 21:48:29.307 | Endpoint type database is available, service trove should be set as available in the config file.
22:35:14 <dkranz> 2014-12-11 21:48:29.307 | Endpoint type network is available, service neutron should be set as available in the config file.
22:35:14 <dkranz> 2014-12-11 21:48:29.307 | Endpoint type orchestration is available, service heat should be set as available in the config file.
22:35:17 <dkranz> 2014-12-11 21:48:29.799 |
22:35:23 <dkranz> mtreinish: then fail hard
22:35:33 <dkranz> mtreinish: speaking of devstack ...
22:35:51 <mtreinish> dkranz: hmm, that looks like verify-tempest-config-output I wonder if that patch broke things
22:35:55 <mtreinish> dtroyer: are you around?
22:35:57 <dkranz> mtreinish: I think so
22:36:08 <dkranz> mtreinish: It is that script output. I checked.
22:36:10 <dtroyer> heyo…I just had two specs to mention
22:36:27 <mtreinish> dkranz: we can debug on -qa after the meeting
22:36:33 <dkranz> mtreinish: k
22:36:34 <mtreinish> in the short term we can revert it
22:36:48 <mtreinish> dtroyer: ok
22:36:48 <dtroyer> One is chmouel's on extending the plugin stuff to load from out of the devstack repo by only setting local.conf
22:37:18 <dtroyer> the other I just posted yesterday about the logging and service name changes we talked about in Paris
22:37:20 <dstanek> dtroyer: does that exist alreadY/
22:37:29 <dstanek> err...already?
22:37:34 <dtroyer> dstanek: just the spec
22:37:57 <dstanek> dtroyer: ok, i'll go look for it; i wrote some code to do something similar i think
22:38:04 <mtreinish> #link https://review.openstack.org/#/c/137054/
22:38:07 <mtreinish> dstanek: ^^^
22:38:17 <dtroyer> the logging changes involve d-g and grenade, I'm still trying to sort out just how far into both of those we need to go (not much I think)
22:39:09 <mtreinish> ok, cool
22:39:20 <dtroyer> oh, I jsut saw the pre-caching in the agenda…who's talking about that?
22:39:26 <mtreinish> dtroyer: I am
22:39:27 <mtreinish> dtroyer: how did you want to handle reviews and approvals for devstack specs?
22:40:05 <mtreinish> for tempest the consensus was to have me +A everything (which I'm not necessarily the biggest fan of)
22:40:18 <mtreinish> do you want to be the primary approver on all specs?
22:40:42 <dtroyer> by default the same as devstack reviews…I could do that but I don't want to be a BDFL on devstack either
22:41:21 <dtroyer> even though that may be the case currently
22:41:52 <mtreinish> dtroyer: heh, ok. I'll add a reviewing doc to the specs repo this week to document things
22:41:58 <mtreinish> since the program keeps on growing
22:42:09 <mtreinish> anyway about precaching images
22:42:13 <dtroyer> I thinkk I just realized that we put the blueprints for both of those specs under tempest too…I'll move them
22:42:24 <mtreinish> heh, ok
22:42:32 <mtreinish> we landed this today:
22:42:34 <mtreinish> #link https://review.openstack.org/#/c/140462/
22:42:42 <mtreinish> which added a new image to devstack
22:43:02 <mtreinish> but in the gate, we precache all the images so we don't go out to the internet to download during the run
22:43:07 <mtreinish> which is slow and unreliable
22:43:32 <mtreinish> so I wanted to propose adding a new way to handle adding or changing images in devstack
22:44:13 <mtreinish> where we hard code a new or changed image to a separte file first and wait 24 hours before we use it (and remove it from the staging file)
22:44:27 <mtreinish> that way we let nodepool precache anything before we use it
22:44:59 <dtroyer> maybe have a simple cache manager that provides the list to the download side, and maps those to stack.sh.  that should also get the absolute URLs out of the code
22:45:50 <mtreinish> dtroyer: oh, yeah that works too, we would have to be sure not to update the mapping on the first pass though
22:45:59 <mtreinish> otherwise it would cause the same problem
22:46:33 <dtroyer> or since this case was just moving to the next release, keep a backup in case the new image hasn't downloaded yet
22:46:34 <adam_g> isn't that what tools/image_list.sh already does?
22:47:09 <adam_g> well, for compute driver image requirements, at least. i was looking at extending that to support pre-caching of images used by DIB for image builds
22:47:10 <dtroyer> partially, but it doesn't factor the URLs out of the scripts.
22:47:52 <mtreinish> dtroyer: yeah if there was logic to have multiple file names for one image and a fallback to the backup that would work
22:48:16 <mtreinish> ok well there are a couple of ways to solve this, we can take it offline to -qa after the meeting
22:48:29 <mtreinish> does anyone have anything else to add on devstack?
22:49:21 <mtreinish> ok, let's move on then
22:49:24 <mtreinish> #topic Grenade
22:49:36 <mtreinish> jogo, sdague, dtroyer: anything new on grenade this week?
22:50:32 <dtroyer> nothing from me beyond the logging investogation
22:50:56 <mtreinish> ok, then let's move on. Because I haven't seen to much motion there either
22:51:00 <mtreinish> #topic Bugs
22:51:08 <mtreinish> #link https://etherpad.openstack.org/p/Tempest-bug-report
22:51:14 <mtreinish> gmann: any update on bugs this week
22:51:30 <mtreinish> masayukig: looks like you had the triage rotation this week: https://etherpad.openstack.org/p/qa-bug-triage-rotation
22:51:44 <mtreinish> and I'm up next week
22:51:52 <gmann> mtreinish: nothing much, we keep count low.
22:52:07 <mtreinish> gmann: ok that's good. We do need to start clearing out the backlog too :)
22:52:15 <mtreinish> but that's always been slow
22:52:32 <gmann> masayukig did bug triage this week
22:52:38 <masayukig> gmann: yeah, we've done :)
22:53:14 <mtreinish> does anyone have anything else to add on bugs?
22:53:26 <gmann> mtreinish: thats all from my side
22:53:40 <mtreinish> gmann: ok, thanks
22:53:56 <mtreinish> #topic Critical Reviews
22:54:11 <mtreinish> does anyone have any reviews they'd like to bring up and get extra eyes on?
22:55:11 <mtreinish> really, no one :)
22:55:13 <adam_g> i have one
22:55:14 <adam_g> :)
22:55:17 <adam_g> #link https://review.openstack.org/#/c/140512/
22:55:34 <adam_g> its already been reviewed but required a new patchset, should be good now. minor change to hopefully close a gate race
22:55:38 <mtreinish> dtroyer: any concerns if I self +A: https://review.openstack.org/140090
22:55:55 <mtreinish> adam_g: ok, I'll take a look soon
22:56:03 <dtroyer> mtreinish: go ahead
22:57:07 <mtreinish> adam_g: so we're adding a 2 min wait to devstack runs...
22:57:23 <mtreinish> is there anyway to improve that?
22:57:45 <adam_g> mtreinish, we're not necessarily waiting 2 mins, thats just the timeout
22:57:58 <adam_g> mtreinish, alternatives would be to decrease periodic task polling interval in both nova and ironic
22:58:18 <mtreinish> which could increase cpu load, hmm yeah I guess it's fine
22:58:56 <adam_g> worst case is we wait for 3 sets of periodic tasks to run: n-cpu, ir-cond, n-cpu
22:58:57 <mtreinish> and since we dropped xml testing we've got a lot of the time budget back
22:59:45 <mtreinish> ok, if there aren't any other reviews I guess we'll end here
23:00:11 <mtreinish> #endmeeting