17:00:26 <mtreinish> #startmeeting qa
17:00:31 <openstack> Meeting started Thu May 12 17:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:34 <openstack> The meeting name has been set to 'qa'
17:00:43 <rlrossit> o/
17:00:45 <mtreinish> hi, who's here today?
17:00:51 <slowrie> <
17:00:51 <fnaval_> o/
17:00:53 <fnaval_> hi
17:01:36 <fnaval> o/
17:01:53 <andreaf> o/
17:02:06 <mtreinish> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_May_12th_2016_.281700_UTC.29
17:02:10 <mtreinish> ^^^ today's agenda
17:02:43 <hogepodge> o/
17:02:47 <mtreinish> ok, let's get started
17:02:49 <rfolco> o/
17:02:55 <mtreinish> #topic Specs Reviews
17:03:04 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
17:03:22 <mtreinish> so there are a couple of specs reviews open that look to be in a state they can merge
17:03:31 <mtreinish> does anyone want to discuss an open spec review?
17:04:00 <mtreinish> rlrossit: ???
17:04:02 <rlrossit> mtreinish: I have some questions as to what I should do with my spec. Where should it live?
17:04:10 <rlrossit> like it's not really tempest
17:04:30 <rlrossit> I guess the spec is even more of just a general initiative kinda thing
17:04:33 <mtreinish> rlrossit: oh, about the dir structure, yeah I guess we don't really have a place for other projects
17:04:52 <mtreinish> rlrossit: we probably should add another dir (or just pick up things in the root dir)
17:05:04 <mtreinish> rlrossit: I'll push a patch to reorganize things and rebase your's on top of it
17:05:12 <rlrossit> I would also like to see what interest there is around testing permissions/policies in folks' clouds
17:05:24 <mtreinish> the last time this came up I think we just jammed it in devstack, which wasn't really correct
17:05:38 <rlrossit> I'm thinking it might be a little more relevant now that https://review.openstack.org/#/c/290155/5/specs/newton/approved/policy-in-code.rst exists
17:05:57 <mtreinish> #link https://review.openstack.org/314704
17:06:05 <mtreinish> ^ that's what we're discussing
17:06:20 <rlrossit> oh right, the link. Thanks mtreinish ;)
17:07:00 <mtreinish> rlrossit: well, I think that helps make the weird stuff you're doing in your cloud more clear
17:07:17 <mtreinish> but crazy policy decisions have existed before that spec :)
17:08:09 <mtreinish> rlrossit: is there anything else on your spec?
17:08:33 <rlrossit> mtreinish: not really. Other than, have you seen any other role-based testing roll around openstack?
17:09:04 <andreaf> something only slightly relevant is policies in keystone
17:09:10 <rlrossit> I got inspiration from some really strict cloud cafe tests, but I haven't seen anything other than that (and even then, it was only barbican)
17:09:34 <mtreinish> rlrossit: nothing like what you're trying to do. It's come up in bugs every now and then, but most of the upstream testing has implicity assumes a default (more or less) policy file
17:09:57 <andreaf> the type of token needed to access resources in the keystone admin api changes depending on the policy in use
17:10:11 <rlrossit> mtreinish: alright. I don't expect my project to be the final implementation, it was more of just a proof-of-concept kinda thing to say "hey, here's another thing to test"
17:11:19 <andreaf> I'm trying to address some of it in tempest but it's something different from your spec really
17:11:42 <hogepodge> It would be nice if policy testing wasn't mixed in with other capabilities, especially since there's going to be a lag in transitioning from policy file to more card coded
17:12:16 <rlrossit> hogepodge: what do you mean by other capabilities?
17:12:21 <mtreinish> hogepodge: well rlrossit's spec/project implements it all as a standalone tempest plugin
17:12:50 <hogepodge> ah, I see
17:12:52 <hogepodge> great
17:13:15 <andreaf> hogepodge: and my work addresses identity admin API, which should be out of scope for defcore, rigth?
17:13:34 <hogepodge> andreaf: it would be, yes
17:13:40 <mtreinish> ok, the other spec I wanted to bring up was:
17:13:42 <mtreinish> #link https://review.openstack.org/#/c/269934/
17:13:56 <mtreinish> which is for the tempest run work, it'd be good to get review cycles on that
17:14:06 <mtreinish> because I'd like to start to get that moving for real soon
17:15:42 <andreaf> mtreinish: I can review that this week
17:15:47 <mtreinish> andreaf: ok, cool
17:15:50 <mtreinish> thanks
17:16:08 <mtreinish> does anyone have anything else on specs?
17:17:23 <mtreinish> ok, let's move on
17:17:30 <mtreinish> #topic Tempest
17:18:08 <mtreinish> it looks like oomichi put all the Newton priority items on the agenda under this topic
17:18:17 <mtreinish> but I don't expect to talk about each one
17:18:26 <mtreinish> so does anyone have anything they'd like to bring up on tempest?
17:18:32 <slowrie> #link https://review.openstack.org/#/c/283770
17:18:32 <fnaval> yes
17:18:36 <fnaval> #link https://review.openstack.org/#/c/315319/
17:18:38 <slowrie> Still looking for reviews on centralized workspaces
17:18:55 <fnaval> same - reviews requested
17:18:58 <fnaval> please
17:19:00 <mtreinish> slowrie: ok, I'll take a look
17:19:18 <mtreinish> fnaval: I think that's a duplicate of another open patch
17:19:29 <slowrie> mtreinish: I also need for someone else to look @ subunit-describe-calls, already has a +2 from oomichi
17:19:30 <fnaval> yes, so how should we approach that
17:19:32 <slowrie> #link https://review.openstack.org/#/c/312275
17:20:14 <mtreinish> fnaval: well normally the patch which was pushed first is the we work with
17:20:42 <mtreinish> slowrie: ok, not really a tempest thing, but I'll take a look. (the os-testr core team is a bit smaller)
17:20:50 <tosky2> I didn't really check, but what is the status for running plugins in the tempest venv on the CI?
17:20:50 <andreaf> fnaval, mtreinish: I can look at the catalog one, if you find a duplicate let me know
17:20:51 <fnaval> mtreinish: kk, i'll either put a depedency on my patch on that one or just be a co-author of the original
17:20:53 <fnaval> https://review.openstack.org/#/c/284273
17:21:02 <fnaval> #link  https://review.openstack.org/#/c/284273
17:21:23 <mtreinish> andreaf: ^^^ that's the other patch
17:21:29 <fnaval> andreaf: awesome, thanks - I'll ping you when I make the changes
17:21:32 <mtreinish> tosky2: that's landed on the devstack side
17:21:39 <andreaf> fnaval: ok
17:21:39 <mtreinish> so you should be able to use it
17:22:11 <tosky2> oh, good to hear - is it already used by some plugin?
17:22:17 <mtreinish> tosky2: https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack++topic:install-plugins
17:22:27 <tosky2> thanks
17:22:53 <mtreinish> on your project config side you should just need to use the devstack passthrough to set TEMPEST_PLUGIN to the things you want to pip install
17:23:23 <mtreinish> tosky2: https://review.openstack.org/#/c/299888/ is a WIP for doing that with ironic
17:23:33 <mtreinish> (it still has complications because it's an intree plugin)
17:24:19 <mtreinish> ok, does anyone have anything else to discuss on tempest?
17:26:00 <andreaf> we're working on the prio items, but nothing to discuss here from my side
17:26:26 <mtreinish> andreaf: ok
17:26:46 <mtreinish> ok, lets move on then
17:26:55 <mtreinish> #topic DevStack + Grenade
17:27:12 <mtreinish> so there is some big news on this one, but I'll give sc68cal first crack at it
17:27:26 <mtreinish> sc68cal: around?
17:28:01 <sc68cal> around
17:28:38 <sc68cal> So - we landed the new lib/neutron yesterday, but it's still got a few things to fix that I made mistakes on
17:29:00 <mtreinish> sc68cal: you're supposed to gloss over mistakes :)
17:29:01 <andreaf> yay!! \o/
17:29:35 <slowrie> mtreinish: they're features not mistakes
17:29:43 <sc68cal> mtreinish: heh. Well, I want to make sure I keep everyone's expectations in check
17:29:47 <clarkb> sc68cal: is it in use if you enable neutron or has that switch not been made yet?
17:30:35 <sc68cal> clarkb: the switch hasn't been made yet, I have a patch up that makes the switch and tests neutron, we have some failures I need to track down. It's mostly just making sure I configure the *bare minimum* for everything to function
17:32:03 <jlvillal> o/  very late
17:32:22 <mtreinish> sc68cal: is there a deprecation plan for neutron-legacy, like are we just gonna make a hard cut
17:32:23 <sc68cal> so, I'll keep plugging away at it, and once it's more presentable I'll put something on the ML on how to use, although the commit message for it does cover how to use it
17:32:36 <mtreinish> or do a real deprecation period (with a warning being emitted) first
17:33:15 <sc68cal> mtreinish: I think once we switch over the neutron CI jobs to lib/neutron - we can probably do a hard cut
17:33:27 <mtreinish> sc68cal: ok, cool
17:33:27 <sc68cal> since that'll be the hardest part
17:33:42 <sc68cal> but putting in a deprecation warning in advance sounds good to me
17:35:06 <mtreinish> ok, is there anything else to discuss on devstack and grenade this week?
17:35:12 <mtreinish> oh, rfolco you put something on the agenda
17:35:47 <rfolco> mtreinish, oops got disconnected at the right time :)
17:36:14 <mtreinish> heh
17:36:19 <rfolco> mtreinish, I�d like to hear thoughts about enabling mariadb for devstack on ubuntu.
17:36:19 <rfolco> #link https://review.openstack.org/#/c/314087/
17:36:42 <rfolco> The original proposal was to allow users choosing between mysql flavors (MySQL/MariaDB) on Ubuntu.
17:36:53 <mtreinish> rfolco: hmm, so in the past we haven't really made an opinion on it, we just use the distro default
17:37:10 <mtreinish> which is maria on fedora and mysql on ubuntu
17:37:44 <mtreinish> personally I'm leaning towards doing something like enabling maria on ubuntu as a devstack plugin
17:37:52 <mtreinish> and leave the default path to just be the distro default
17:38:07 <sc68cal> ++
17:38:43 <rfolco> looks good, ubuntu must have a reason for keeping mysql as default
17:39:33 <rfolco> ok mtreinish would propose something as a plugin instead
17:40:00 <mtreinish> rfolco: that I can't tell you. Although my internal conspiracy theorist wants to say there is a secret cabal with oracle and canonical
17:40:18 <mtreinish> rfolco: ok, cool
17:40:25 <tosky2> or simply because debian did not switch yet...
17:40:27 <mtreinish> is there anything else to discuss on devstack or grenade?
17:40:49 <rfolco> right! mariadb is the community fork for mysql :)
17:41:36 <mtreinish> ok, let's move on
17:41:52 <mtreinish> #topic Openstack-Health
17:42:11 <mtreinish> so just quickly on this I wanted to discuss:
17:42:13 <mtreinish> #link https://review.openstack.org/311919
17:42:31 <mtreinish> which is for enabling elastic-recheck support to openstack-health
17:42:49 <slowrie> mtreinish: were you able to solve the initial performance issues you were having?
17:42:54 <mtreinish> right now the biggest blocker on it is the performance of the actually elasticsearch querying
17:43:19 <mtreinish> slowrie: sort of, I got the combined api query down to ~20 sec by hitting es in parallel
17:43:37 <mtreinish> I haven't had a chance to do more indepth profiling of where it's spending the time yet
17:43:46 <slowrie> would this be a case for something we would run server side at specific times to try to just cache known bugs?
17:44:11 <mtreinish> so making it update periodically was probably gonna be my next step
17:44:22 <mtreinish> because this doesn't have to be real time
17:44:44 <mtreinish> we already have caching enabled for that rest api call in the js
17:44:57 <mtreinish> but I'm thinking it'll need to be more explicit
17:45:10 <mtreinish> the problem is we don't have any manual caching mechanisms in place yet
17:45:22 <slowrie> I'll take a look when I get my next block of free time
17:45:36 <mtreinish> ok, cool thanks
17:45:49 <mtreinish> does anyone have anything else they'd like to discuss on openstack-health?
17:45:57 <slowrie> On another note, I have managed to get subunit2sql working with json fields
17:46:10 <slowrie> Currently building database size to do some proper benchmarking
17:46:17 <fnaval> it's a useful dashboard
17:46:24 <mtreinish> slowrie: oh cool, I'm curious to see how that performs
17:46:34 <slowrie> mtreinish: On a small scale it's not noticable yet
17:46:36 <andreaf> slowrie: to store metadata?
17:46:38 <slowrie> Yeah
17:46:59 <slowrie> andreaf: it completely removes any kvp metadata tables and just stores them natively
17:47:05 <andreaf> nice, looking forward to results as well :)
17:47:07 <slowrie> Current issues that are definite blockers though
17:47:11 <mtreinish> it'll get tricky enabling that in a generic way (considering the backend requirements) but it should be doable
17:47:16 <slowrie> It requires sqlalchemy 1.1 which is still dev
17:47:26 <slowrie> and it requires either a change to postgre or mysql 5.7
17:47:33 <andreaf> oh ok
17:47:55 <mtreinish> slowrie: right, that's the tricky bit because we have to handle the case where that isn't what's being used
17:48:06 <mtreinish> like sqlite...
17:48:22 <mtreinish> but it's something we can work on when the time is right
17:48:24 <slowrie> mtreinish: yeah, currently on my dev box it's just using an alembic revision only for mysql
17:49:01 <mtreinish> ok, is there anything else on this topic?
17:49:47 <andreaf> mtreinish: we talked at the beginning of o-h or before that about tracking changes in the amount of tests executed
17:50:09 <andreaf> mtreinish: is this something that you think it would be interesting still to highlight on the dashboard
17:50:10 <andreaf> ?
17:50:21 <mtreinish> andreaf: it already does that to some extent on the per job page
17:50:28 <mtreinish> it shows raw test counts for everything there
17:50:43 <mtreinish> we probably can refine it a bit or add a view to show tests per run
17:50:54 <mtreinish> but I think that's fine to work on
17:51:57 <mtreinish> ok, lets move on
17:52:05 <mtreinish> #topic Critical Reviews
17:52:17 <mtreinish> does anyone have any reviews they'd like to get extra eyes on?
17:52:36 <mtreinish> I've got a couple:
17:52:38 <mtreinish> #link https://review.openstack.org/314673
17:52:46 <mtreinish> #link https://review.openstack.org/314775
17:54:12 <mtreinish> no one else has any reviews to bring up?
17:54:14 <andreaf> mtreinish: ok added to my list
17:54:27 <mtreinish> andreaf: thanks
17:54:36 <mtreinish> they both are super straightforward
17:54:44 <andreaf> mtreinish: I would like opinions on https://review.openstack.org/#/c/313171/
17:54:56 <andreaf> mtreinish: the scope thing in auth.py
17:55:09 <mtreinish> #link https://review.openstack.org/#/c/313171/
17:55:31 <mtreinish> I could swear I've reviewed that several times already :)
17:56:35 <mtreinish> andreaf: I'll take another look, but I seem to remember it being close and mostly being +2 when it was back tempest-lib
17:57:00 <andreaf> heh I changed it a bit based on jordanP input, made it simpler I think
17:57:18 <mtreinish> ok, cool
17:58:01 <mtreinish> ok, if there aren't any other reviews let's open the floor for 2 min
17:58:02 <andreaf> the thing is when I use domain scoped tokens it doesn't work on liberty - only mitaka and newton, so I think I'll have to add a config option
17:58:06 <mtreinish> #topic Open Discussion
17:58:23 <mtreinish> andreaf: why, that should be something that works fine on liberty too
17:58:30 <mtreinish> not that we ever really test it
17:58:47 <mtreinish> andreaf: we should circle back with jamielennox or someone after the meeting
17:59:59 <slowrie> after some more research it does look like there's a json1 extension for sqlite & mariadb supports json fields as of 10.0.1
17:59:59 <mtreinish> ok, well we're basically at time, so let's end here
18:00:03 <mtreinish> thanks everyone
18:00:09 <mtreinish> #endmeeting