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