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