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