17:01:21 <sdague> #startmeeting qa 17:01:21 <openstack> Meeting started Thu Jun 13 17:01:21 2013 UTC. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:24 <openstack> The meeting name has been set to 'qa' 17:01:26 <ravikumar_hp> sdague: hi 17:01:48 <sdague> ok, who else is around? 17:01:53 <mlavalle> Hi 17:01:55 <davidkranz> sdague: Here 17:02:03 <mpavlase> o/ 17:02:07 <donaldngo_hp> hello 17:02:31 <mtreinish> hi 17:02:37 <afazekas> hi 17:03:27 <sdague> so, I was lame, and didn't get around to setting up an agenda this week. So lets do the regular stuff: Blueprints, Crictical Reviews, then open discussion 17:03:37 <sdague> #topic Blueprints 17:04:03 <sdague> #link https://launchpad.net/tempest/+milestone/havana-2 17:05:36 <sdague> ok, havana-2 is there, any updates from folks? 17:05:59 <sdague> I'm going to make it a fast meeting if no one else speaks up :) 17:06:16 <mtreinish> sdague: nothing from me... 17:06:17 <afazekas> speed up tempest 17:06:23 <ravikumar_hp> sdague: I will start submitting from next week 17:06:31 <sdague> ravikumar_hp: ok good 17:06:35 <ravikumar_hp> Keystone and network 17:06:40 <sdague> mtreinish: want to give an update on the testr state of things? 17:07:38 <sdague> anyone else with blueprint updates? 17:07:41 <mtreinish> sdague: so I've got the fixtures prototype out there now. I'm working on using the testtools extension test suite FixtureSuite for the list tests 17:07:50 <sdague> mtreinish: cool 17:08:05 <davidkranz> mtreinish: Any comment about the cleanup performance issue? 17:08:25 <mtreinish> FixtureSuite (at least according to the testtools documentation) does the fixture setup before all the tests and cleanup after all the tests which is what we are looking for 17:08:35 <mtreinish> but I'm not sure how it integrates with testr (if at all) 17:08:43 <davidkranz> mtreinish: I meant the one-phase vs two-phase issue. 17:08:50 <mtreinish> davidkranz: I haven't had a chance to look at your suggestion about the 2 phase cleanup yet 17:09:01 <davidkranz> mtreinish: That's OK. 17:09:20 <mtreinish> davidkranz: but it sounds like it could be used to solve the issue 17:09:25 <davidkranz> mtreinish: But I don't think we will be able to live with sequential delete in a large system. 17:09:33 <afazekas> mtreinish: I guess a new runner based on testtools can be implemented which able to call the setupclass, the testtools in theory designed to be extensible 17:09:34 <mtreinish> davidkranz: no we won't 17:10:05 <davidkranz> mtreinish: Just saying I think we need to solve that problem before committing this kind of change. 17:10:10 <sdague> davidkranz: honestly, I wouldn't worry too much about solving that problem in advance though. We need to do it eventually 17:10:24 <afazekas> mtreinish:This can be the fastest way to have have PoC with testr subunit testtools .. 17:10:38 <sdague> but we're going to go to 4 tests running in parallel so the delete case may very well still not hurt us 17:11:04 <sdague> we'll see what the timing looks like across the suite as a whole 17:11:24 <sdague> ok, anything else on blueprints? 17:11:24 <mtreinish> sdague, davidkranz: yeah it should only really be a hit on things like the list tests where we create and delete multiple resources per test 17:11:37 <adalbas> yes, sdague , about the grenade on the gate 17:11:39 <davidkranz> sdague: I agree with you in upstream but people are running tempest on larger systems downstream. 17:12:01 <sdague> davidkranz: but our tests define the number of resources 17:12:04 <mtreinish> afazekas: yeah it probably will, I plan to look at it after I'm finished my FixtureSuite experiment 17:12:28 <sdague> if downstream has forked tempest which they haven't contributed back, it's not that concerning to me 17:12:56 <sdague> adalbas: go for it 17:13:08 <davidkranz> sdague: I'm only saying this because it should be fairly simple to fix. I am not talking about forking downstream, just running. 17:13:20 <davidkranz> Anyway, we can move on. 17:13:30 <adalbas> there is one issue that glance show is returning deleted images 17:13:38 <sdague> davidkranz: right, we might be talking across each other 17:13:49 <mtreinish> adalbas: is that the one you asked me about from before 17:13:50 <sdague> adalbas: cool, has the bug been registered on glance? 17:13:55 <adalbas> and this is causing one of the tempest smoke tests to fail 17:14:00 <adalbas> mtreinish, yes. 17:14:06 <adalbas> the devstack environment is ok 17:14:11 <adalbas> but not on grenade 17:14:18 <adalbas> that might be something about the upgrade 17:15:01 <adalbas> not sure if something changed on the db schema. I looked over config files and there seem to be nothing that would cause this there 17:15:12 <sdague> ok, sounds like an issue we should bring into the #openstack-qa channel, as if that's the last thing holding up gating on grenade, we want to get to the bottom of it 17:15:19 <afazekas> abalbas: are you speaking about the image_2id exception ? (Or something similar) 17:15:28 <sdague> but probably not debug in this meeting 17:15:40 <adalbas> sure sdague 17:15:58 <sdague> ok, let's jump to reviews that people need 17:16:05 <sdague> #topic Reviews Needed 17:16:08 <mpavlase> what 'grenade' means in OpenStack context? 17:16:13 <sdague> ok, time to pimp your reviews 17:16:27 <sdague> mpavlase: grenade is upgrade testing, going from grizzly -> master 17:16:41 <mtreinish> mpavlase: https://wiki.openstack.org/wiki/Grenade 17:16:49 <mpavlase> sdague: thank you 17:16:59 <sdague> #link https://wiki.openstack.org/wiki/Grenade 17:17:12 <sdague> ok, any reviews people need eyes on? 17:17:24 <adalbas> https://review.openstack.org/#/c/31961/ 17:17:36 <adalbas> and https://review.openstack.org/#/c/32460/ 17:17:42 <sdague> #link https://review.openstack.org/#/c/31961/ 17:17:47 <sdague> #link https://review.openstack.org/#/c/32460/ 17:17:54 <adalbas> tks sdague 17:18:37 <sdague> ok, I'll take a look after the meeting 17:18:40 <afazekas> adalbas: is your flavor response line contains the same id in the [0] and [1] index ? 17:18:42 <sdague> any other ones 17:19:10 <adalbas> yes afazekas 17:19:52 <adalbas> it gets the default_instance_type and when it builds the array, the value is duplicated in the first 2 positions 17:20:18 <adalbas> going over a loop would eliminate that 17:20:21 <afazekas> makes sense 17:21:17 <sdague> adalbas: cool, great 17:21:27 <sdague> any other reviews? 17:21:44 <sdague> #topic Open Discussion 17:21:52 <sdague> ok, open discussion, any other topics? 17:22:06 <davidkranz> #topic Multinode testing 17:22:22 <davidkranz> Is this on our roadmap now? 17:22:53 <davidkranz> I thought it was but can't find mention of it anywhere. 17:22:56 <afazekas> It is on my road map, I do not know what is the others opinion. 17:23:13 <davidkranz> afazekas: Is there a blueprint? 17:23:13 <sdague> davidkranz: no one had brought in a blueprint with a committed schedule on it 17:23:31 <sdague> so there is no targetted havana blueprint at this point 17:23:37 <davidkranz> sdague: What do we need from ci? 17:24:02 <sdague> davidkranz: I don't know, that would all be part and parcel of the blueprint 17:24:30 <davidkranz> sdague: I'll ask the ci folks then. 17:25:26 <sdague> I expect this to be a lot of work, as you'll need to coordinate devstack installs across 2 nodes 17:25:47 <sdague> it's a good thing to work, for sure, just realize it's a lot of heads down time 17:25:50 <davidkranz> sdague: Yes, and get the two nodes in the first place. 17:26:18 <sdague> would be great to have an owner driving this 17:26:30 <davidkranz> sdague: I'll work on that. 17:26:39 <sdague> cool 17:26:59 <sdague> other topics for discussion? 17:27:04 <sdague> #topic Open Discussion 17:27:30 <sdague> going once.... 17:27:48 <sdague> going twice.... 17:27:54 <afazekas> module import 17:27:59 <sdague> ok 17:28:22 <sdague> afazekas: go for it 17:28:36 <afazekas> Do we want to follow this hacking rule , or we want to remove it from the documentation ? 17:28:49 <sdague> I would like to follow it 17:28:56 <mtreinish> afazekas: so we aren't in compliance with this rule at all right now 17:29:00 <mtreinish> it's disabled 17:29:06 <mtreinish> but we should be in compliance I think 17:29:15 <mtreinish> (we want to be) 17:29:16 <sdague> right, but the question is whether we drop it from our guidelines 17:29:39 <sdague> I honestly find reading the code is a lot easier when you don't have to guess where the modules are coming from 17:29:41 <afazekas> 2000 line change, and it does not gives better readability always 17:30:01 <davidkranz> afazekas: Which rule exactly? 17:30:09 <afazekas> import only module 17:30:36 <sdague> afazekas: it doesn't always, but in a lot of cases it does 17:30:39 <davidkranz> afazekas: Oh, I thought we already did that in tempest. I must be wrong. 17:30:44 <sdague> I'd call it a low priority item to fix 17:30:55 <sdague> but I'd still like to see it fixed 17:31:24 <sdague> the only rules I really want us to ignore, personally, are E123 and E125 which definitely overreach 17:32:00 <sdague> ok, other items for discussion? 17:32:07 <mtreinish> sdague: the current ignore list is: E125,H302,H404 17:32:17 <afazekas> The alphabetic order usually tricky when you changes multiple files 17:32:40 <sdague> afazekas: yeh, but it's handy for reading 17:32:52 <sdague> 302 is the import, what's 404 again? 17:32:56 <afazekas> mtreinish: As I remember you also recommended 3 import group 17:33:01 <davidkranz> mtreinish: How do you find out what these codes are? 17:33:08 <mtreinish> sdague: docstring rule 17:33:24 <davidkranz> mtreinish: Where are they defined? 17:33:32 <mtreinish> afazekas: yeah group it by python std lib import, 3rd party, and tempest 17:33:36 <mtreinish> davidkranz: it's in tox.ini 17:33:50 <sdague> davidkranz: the hacking rules are in - https://github.com/openstack-dev/hacking/blob/master/hacking/core.py (HXXX codes) 17:33:50 <afazekas> Probably it is doable to order them by a script if the rule is well defined for this 17:33:54 <sdague> the others are in pep8 17:34:01 <davidkranz> sdague: OK, thanks. 17:34:30 <sdague> tox.ini defines what we skip 17:34:30 <mtreinish> davidkranz: oh, sry I misread what you asked, I thought you asked where the ignore list was 17:35:00 <afazekas> mtreinish: do you have a recommendation to the ordering of the three group ? 17:35:44 <sdague> afazekas: it's in HACKING.rst 17:35:46 <sdague> {{stdlib imports in human alphabetical order}} 17:35:46 <sdague> \n 17:35:46 <sdague> {{third-party lib imports in human alphabetical order}} 17:35:46 <sdague> \n 17:35:46 <sdague> {{tempest imports in human alphabetical order}} 17:36:05 <sdague> there is an example there as well 17:36:35 <sdague> ok, anything else for today? 17:36:38 <afazekas> sdague: "yeah group it by python std lib import, 3rd party, and tempest" 17:37:19 <sdague> going once... 17:37:31 <sdague> going twice... 17:37:56 <sdague> ok, let's take any further discussion to #openstack-qa - it's always open, and good place to chat on all things QA 17:38:01 <sdague> #endmeeting