17:00:32 <mtreinish> #startmeeting qa
17:00:33 <openstack> Meeting started Thu Dec  4 17:00:32 2014 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:36 <openstack> The meeting name has been set to 'qa'
17:00:44 <mtreinish> hi who's here today?
17:00:49 <dkranz> here
17:00:53 <jeff_coho1> hello
17:00:57 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_December_4th_2014_.281700_UTC.29
17:01:01 <mtreinish> ^^^ today's agenda
17:01:23 <andreaf> 0/
17:01:26 <andreaf> o/
17:01:37 <dkranz> :/
17:01:38 * jogo lurks
17:02:00 <yfried_> hi
17:02:07 <mtreinish> dtroyer: just a heads up that the meeting is going on :)
17:02:13 <mtreinish> ok, let's get started
17:02:22 <kirshil> hi
17:02:27 <mtreinish> #topic Tagging removal of Tempest XML support? (mtreinish)
17:02:54 <mtreinish> so I wanted to get input from everyone about whether we should push a new tempest tag
17:03:06 <mtreinish> since we removed all the xml tests from tempest last week
17:03:19 <mtreinish> I felt it could be considered a big enough change to warrant a new tag
17:03:20 <dtroyer> o/
17:03:28 <mtreinish> does anyone have any opinions on this?
17:03:33 <dkranz> mtreinish: it is, but I am not sure who would use it
17:03:40 <dkranz> mtreinish: I don't think I would
17:03:52 <andreaf> dkranz: I was about to ask the same question
17:04:11 <jogo> tags are cheap. so why not
17:04:11 <andreaf> mtreinish: still there's no harm in creating one, for reference
17:04:15 <dkranz> andreaf: true
17:04:16 <yfried_> jogo: +1
17:04:23 <jeff_coho1> +1
17:04:45 <mtreinish> ok, then I'll push tempest-3 out later today to mark the removal of xml
17:05:28 <mtreinish> #action mtreinish to push tempest-3 tag for xml removal
17:05:40 <mtreinish> ok let's move on
17:05:51 <mtreinish> #topic Spec Reviews
17:06:14 <mtreinish> does anyone have any open spec reviews they'd like to bring up?
17:06:49 <dkranz> mtreinish: No, but I feel negligent about not reviewing the current ones. Many are weeks old.
17:07:11 <yfried_> dkranz: maybe we should hold a spec review day?
17:07:15 <mtreinish> dkranz: heh, yeah I feel the same way, I plan to dedicating a lot of time tomorrow to go through the current queue
17:07:35 <dkranz> mtreinish: me too.  Let's call tomorrow spec review day :)
17:07:56 <yfried_> dkranz: I was serious
17:08:12 <dkranz> yfried_: so was I.
17:08:42 <dkranz> yfried_: I think we can take care of them
17:08:48 <yfried_> dkranz: enjoy
17:08:51 <yfried_> dkranz: :)
17:09:06 <mtreinish> ok, if no one has any specs to discuss today, we can move on
17:09:16 <dkranz> andreaf: You up for that too?
17:10:40 <mtreinish> dkranz: I'm sure he is :)
17:10:42 <andreaf> dkranz: sorry I was afk for a minute
17:11:16 <andreaf> mtreinish, dkranz : yes it sounds ok
17:11:24 <mtreinish> #info Tomorrow 12/5 will be an informal specs review day
17:11:29 <mtreinish> #topic Blueprints
17:11:57 <mtreinish> ok, does anyone have an open bp to discuss
17:12:49 <mtreinish> I guess I should bring up:
17:12:52 <mtreinish> #link https://blueprints.launchpad.net/tempest/+spec/branchless-tempest-extensions
17:13:01 <mtreinish> since dkranz you brought this up on the ML
17:13:01 <dkranz> mtreinish: I started on the clients-return-one-value but need to update the blueprint
17:13:10 <mtreinish> dkranz: ok cool
17:13:20 <dkranz> mtreinish: right. I just did not know what the plan was
17:15:07 <dkranz> mtreinish: I would still like it better if we just stopped using 'all'
17:15:31 <jlanoux_> dkranz: +1
17:15:40 <yfried_> mtreinish: you want to add every extension explicitly?
17:15:59 <mtreinish> yeah so the issue with that bp is it's against tempest but the patches are for devstack and devstack-gate so they don't get picked up automatically
17:15:59 <mtreinish> but I respun the devstack patch so it works now
17:15:59 <mtreinish> so hopefully we'll start to get that landed next week
17:15:59 <mtreinish> and we'll be able to add tests for new extensions soon
17:16:00 <mtreinish> sorry my network dropped out
17:16:01 <mtreinish> what was the last message from me? :)
17:16:19 <mtreinish> dkranz: the plan is to stop using all on the stable branches
17:16:40 <dkranz> mtreinish: I got that part
17:16:53 <mtreinish> yfried_: yes that's the plan, the devstack patch uses verify-tempest-config to generate the list of all extensions
17:17:08 <mtreinish> yfried_: https://review.openstack.org/126422
17:17:12 <dkranz> mtreinish: Just not sure what the motivation is for devstack to not write the list
17:17:13 <yfried_> mtreinish: so "all" would still apply to master? just wanted to make that clear?
17:17:21 <dkranz> mtreinish: But it is not a big deal I guess
17:17:27 <mtreinish> yfried_: yes
17:17:56 <mtreinish> dkranz: it's because when a new extension get's added we don't want to have to update things, we should assume all extensions are enabled by default on master testing
17:17:57 <yfried_> mtreinish: ok. I like having the explicit list even in master (I don't like the "all" option) but that's just me
17:18:30 <mtreinish> it comes back to the discovery bugs, which is the reason we have that option in the first place
17:19:14 <yfried_> mtreinish: ok. I just think it would be better if the default in config.py would hold the entire explicit list
17:19:32 <yfried_> mtreinish: makes it easier for newcomers to see and disable what they don't want
17:19:51 <mtreinish> yfried_: and what is that list? if nova adds an extension it's no longer everything
17:20:30 <dkranz> mtreinish: Yes, it would require new extensions to be added to tempest
17:20:31 <yfried_> mtreinish: well, we know what we are checking for, as in skip if not in "extension"
17:21:12 <yfried_> correct me if I'm wrong, but we mostly use the extensions to check if "Ext" or "All"
17:21:30 <yfried_> so just add Ext to the list
17:21:44 <mtreinish> yfried_: yes, that's the issue on master the list is transient
17:21:51 <yfried_> but let's not get stuck on this. maybe a spec is in order
17:21:51 <dkranz> In any event, 'all' is the way it is now
17:22:07 <mtreinish> we'd be capturing a snapshot at 1 time and it wouldn't be correct at any other time necessarily
17:22:23 <mtreinish> dkranz: yes, let's move on we can discuss this more after the meeting if needed
17:22:27 <dkranz> mtreinish: I think there should be a spec if some one wants to change this
17:22:46 <yfried_> dkranz: mtreinish: I'll write a spec. let's move on
17:22:48 <dkranz> mtreinish: because it is a process issue to keep it up to date
17:23:19 <mtreinish> ok does anyone else have an open blueprint to discuss?
17:24:03 <mtreinish> ok, let's move on then
17:24:26 <mtreinish> #topic Devstack
17:24:58 <mtreinish> dtroyer: any updates on devstack?
17:25:21 <dtroyer> The two things I wanted to mention are both spec-related.   I'm writing a spec for the logging/service renaming stuff so that should hit early next week.
17:26:01 <mtreinish> oh, cool
17:26:02 <dtroyer> Chmouel's spec for including plugins from other repos is up and I've just started looking at it.  I think that is our priority right now really.
17:26:17 <mtreinish> ok
17:26:19 <chmouel> o/
17:26:38 <mtreinish> yeah, those are both priorities that I know a lot of people are interested in
17:26:53 <dtroyer> there was a question in there regarding what to do with existing plugins in the devstack repo after that is complete, I'd like to consider moving some of those back out…the criteria for that I expect will be a bit contentous.
17:26:56 <yfried_> chmouel: link?
17:27:10 <chmouel> #link https://review.openstack.org/#/c/137054/
17:27:10 <dtroyer> yfried_: https://review.openstack.org/#/c/137054/
17:27:15 <dtroyer> jinx
17:27:17 <yfried_> tnx
17:27:37 <mtreinish> dtroyer: heh, yeah that criteria could be a bit contentious
17:28:14 <dtroyer> FWIW, my original thoughts regarding layers 1/2/3 still stand and that's where I'm going to start.  this is a non-governance thing, just a devstack thing…
17:28:17 <chmouel> or maybe not, maybe they would be happy to just take care of it?
17:28:29 <chmouel> (of their devstack's plugin)
17:28:59 <dtroyer> being in the repo is like being incubated…it's a flag for others to know if something is "OK"
17:29:26 <mtreinish> dtroyer: yeah I think that's fine, I'd be even inclined to say just layers 1 and 2 in devstack
17:29:51 <mtreinish> but I think something like that is fine
17:29:55 <mtreinish> as long as we make it clear
17:29:56 <dtroyer> on other news, I'm also looking at the various things that want to muck around with LVM handling now.  it needs some attention, as-is we could wind up with 3 or 4 backing files to manage, each differently
17:30:54 <dtroyer> that's it for me, anyone else?
17:31:47 <mtreinish> ok, let's move on then
17:31:54 <mtreinish> #topic Grenade
17:32:12 <mtreinish> jogo, dtroyer, sdague: are there any updates on grenade this week?
17:33:45 <jogo> there was a but of unbreak the world work
17:33:49 <jogo> https://review.openstack.org/#/q/project:openstack-dev/grenade+is:merged,n,z
17:33:54 <jogo> but thats it
17:34:04 <mtreinish> oh, yeah all the reqs fun from new oslo releases...
17:34:13 <jogo> hehe
17:34:30 <mtreinish> ok well if there's nothing else on grenade we'll move on
17:34:50 <mtreinish> #topic
17:34:55 <mtreinish> #undo
17:34:56 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3b5b4d0>
17:35:00 <mtreinish> #topic Future of "large-ops" testing
17:35:11 <mtreinish> yfried_: I'm guessing you added this
17:35:15 <yfried_> mtreinish: yeah
17:35:21 <yfried_> so I have 2 issues
17:35:50 <yfried_> 1 - is the current test.
17:36:19 <yfried_> It's **only** a nova test
17:36:46 <yfried_> and I am not sure what is the value of having it run both with neutron and with nova
17:36:51 <jogo> yfried_: well actually it hit a bug in rootwrap
17:37:01 <jogo> which was python is dumb
17:37:47 <yfried_> jogo: weird, because as much as I understand it, currently it boots the VM without any neutron involvment
17:37:56 <jogo> yfried_: nova uses rootwrap too
17:38:14 <yfried_> either way - do we need it to run 3x2 times on each patch?
17:38:14 <jogo> yfried_: large-ops on neutron is not an ideal test IMHO
17:38:33 <yfried_> jogo: don't spoil my next point please:)
17:38:34 <jogo> but when setting it up we caught several neutron bugs
17:38:42 <jogo> 3x2?
17:38:59 <yfried_> (neutron, nova) x (master, juno, icehouse)
17:39:08 <jogo> ohh tempest fail
17:39:22 <jogo> yeah I don't think we need to run large-ops on juno and icehouse IMHO
17:39:36 <yfried_> jogo: so removing 4 gates is a good start
17:39:45 <mtreinish> yeah, I think we can drop those stable sanity jobs on tempest
17:39:49 <yfried_> can we agree on that?
17:40:26 <mtreinish> yfried_: push a patch out to do it
17:40:31 <mtreinish> and I'll review it
17:40:32 <yfried_> mtreinish: will do
17:40:43 <jogo> the risk is we make the large-ops test stricter and break stable branches
17:41:02 <yfried_> jogo: could you please explain?
17:41:09 <jogo> yfried_: yes
17:41:28 <jogo> yfried_: if we make the tempest large-ops test do more
17:41:37 <jogo> and its only tested against master
17:41:51 <yfried_> jogo: that's my next point
17:41:55 <jogo> due to branchless tempest, we can break large-ops for stable/*
17:42:08 <dkranz> jogo: This is the dirty laundry of branchless tempest
17:42:10 <jogo> we can move stable large-ops to experimental or something
17:42:21 <jogo> dkranz: yup
17:42:27 <mtreinish> jogo: yeah that's fine
17:42:40 <yfried_> jogo: I'd like to extend large ops into a multi-boot test with actual vms and network
17:42:43 <mtreinish> dkranz: heh that's a good way to describe it
17:43:09 <jogo> yfried_: that is very risky due to small devstack vms in the gate
17:43:17 <yfried_> https://review.openstack.org/136789
17:43:33 <jogo> yfried_: why not make nova fake virt driver do more networking?
17:43:33 <yfried_> jogo: it won't necesserily run 100 vms on gate
17:43:45 <jogo> yfried_: still, it doesn't take a lot to overload a tiny gate VM
17:43:51 <yfried_> jogo: well, I'm completely unfamiliar with the fake virt driver
17:44:22 <jogo> yfried_: http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/fake.py
17:44:23 <yfried_> jogo: we can start with 2-4 vms in a test (secgroup scenario does that already)
17:44:45 <jogo> yfried_: so large-ops is a different job because it uses the fake virt driver
17:44:56 <jogo> so it needs a different devstack setup
17:45:02 <mtreinish> yfried_: think of this way when we were running 8 threads in the gate (ie booting 8 servers at once) things fell apart because of the load
17:45:35 <yfried_> mtreinish: so 2 vms only on the gate, in an experimental job
17:46:02 <yfried_> mtreinish: my main target here is to have a test for operators to run with stress framework
17:46:02 <mtreinish> yfried_: we do that now indirectly on regular jobs
17:46:15 <yfried_> mtreinish: not in a single command
17:46:48 <mtreinish> yfried_: we have a stress job defined and you can add additional configs to it
17:46:50 <yfried_> mtreinish: I already found a bug in neutron<-> nova events while working on it
17:47:06 <mtreinish> yfried_: we can take this to -qa, and dkranz or I can show you how to add on to that
17:47:11 <sdague> so the reality is large-ops honestly isn't really a tempest test
17:47:19 <sdague> it's a specific greybox test
17:47:36 <sdague> that got jammed into tempest because we were doing a lot of jamming
17:47:57 <dkranz> sdague: true, but there could be a stress test that is a lot like it, no?
17:48:23 <sdague> dkranz: so maybe, except it won't actually do anything of the stressing we care about in that case
17:48:31 <dkranz> yfried_: Why don't you consider what you are trying to do to be a "new" test and get away from the large-ops test?
17:48:47 <yfried_> dkranz: yeah, that's what I'm trying to convey
17:48:55 <dkranz> yfried_: There is too much baggage around the large-ops test
17:49:01 <dkranz> yfried_: so call it something else
17:49:05 <yfried_> maybe starting with large ops as base was wrong
17:49:17 <mtreinish> so we're at ~10min so we can take this to -qa after the meeting
17:49:21 <yfried_> I was just looking to reuse some of the code
17:49:27 <dkranz> yfried_: doesn't matter
17:49:28 <mtreinish> yfried_: or right a spec with what you're trying to do and we can discuss it there
17:49:34 <mtreinish> s/right/write
17:49:40 <yfried_> mtreinish:very well. I'm done
17:49:53 <mtreinish> ok
17:49:58 <mtreinish> #topic Critical Reviews
17:50:16 <mtreinish> ok does anyone have a review to bring up for a qa project that they'd like extra eyes on?
17:50:51 <kirshil> yeah ipv6 related in particular https://review.openstack.org/#/c/117458/
17:51:06 <mtreinish> #link https://review.openstack.org/#/c/117458/
17:51:10 <jogo> https://review.openstack.org/54403
17:51:24 <dkranz> mtreinish: I don't have a specific one, but there a fair number of reviews that are pretty old.
17:51:45 <mtreinish> dkranz: do you want to schedule another review day?
17:51:53 <mtreinish> jogo: wow that's a low number
17:51:57 <kirshil> #link https://review.openstack.org/#/c/112336/
17:51:59 <jogo> that is a year old ^_^
17:52:35 <mtreinish> kirshil: ok, I'll try to take a look at those today
17:52:37 <dkranz> mtreinish: ok. I think I may also add something to the project review panel for no action in 7 days, and put it at the top
17:52:51 <sdague> jogo: yeh, honestly, these are the kinds of rules I sort of hate in hacking
17:52:54 <mtreinish> dkranz: it should already have a section for that
17:52:57 <dkranz> mtreinish: We have one for no action after 2 days at the bottom
17:53:24 <sdague> so you realize that the H30* rules are part of the reason that we've lost a ton of useful git history in file moves, right?
17:53:44 <dkranz> mtreinish: but maybe my dashboard is out of date
17:54:17 <mtreinish> dkranz: no, I think that's right. You can push another patch to sdague's project to reorder or add a section
17:54:25 <mtreinish> I think that's fine
17:54:54 <sdague> dkranz: yeh, I have a 5 days no action at the top of the nova one
17:55:12 <dkranz> sdague: ++
17:55:14 <clarkb> sdague: wait the history is still there
17:55:14 <sdague> dkranz: just let me know what change you want to the qa dashboard
17:55:17 <jogo> lost history?
17:55:21 <clarkb> sdague: you shouldn't lose any history in a file move
17:55:29 <dkranz> sdague: I can do it myself if you remind me which repo
17:55:30 <sdague> clarkb: you can't git log the file any more and trace it back
17:55:34 <jogo> I am fine with dropping H30x or whatever, I just want to resolve this
17:55:43 <clarkb> sdague: not on the file name but you can still git log on it
17:55:49 <sdague> clarkb: right
17:56:05 <sdague> but it means that tracing back a git annotate gets pretty hard
17:56:14 <clarkb> sdague: not really, use the power of -p
17:56:26 <sdague> clarkb: ok, show me the tricks then :)
17:56:29 <clarkb> or at least that seems to be my swiss army knive of looking at history
17:56:34 <clarkb> sdague: git log -p
17:56:44 <clarkb> its pretty verbose but you can use other options to narrow the output down
17:56:50 <jogo> --follow
17:56:53 <clarkb> and it gives you full diff history along the way
17:57:11 <clarkb> also ya follow. -p is useful for >1 file
17:57:22 <sdague> oh, but I can't get the annotate though, right?
17:57:44 <mtreinish> well were at ~3min so does anyone else have a review to bring up
17:57:49 <mtreinish> otherwise we'll end here
17:57:53 <jogo> so this specific path https://review.openstack.org/#/c/54403
17:57:54 <clarkb> I think you can usually you can compose those options /me tests
17:58:06 <jogo> is there to make the error message easier to understand
17:58:26 <clarkb> oh you mean git blame?
17:58:42 <jogo> https://bugs.launchpad.net/bugs/1392525
17:58:44 <uvirtbot> Launchpad bug 1392525 in hacking "H307 being raised when import block is in the wrong order" [Critical,In progress]
17:58:55 <sdague> clarkb: yeh
17:59:05 <sdague> annotate is the nice way to say it thought
17:59:15 <mtreinish> sdague: but blame is better :)
17:59:46 <mtreinish> anyway we're basically at time
17:59:51 <mtreinish> thanks everyone
17:59:55 <mtreinish> #endmeeting