09:00:03 <gmann> #startmeeting qa
09:00:04 <openstack> Meeting started Thu Apr  6 09:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:07 <openstack> The meeting name has been set to 'qa'
09:00:13 <gmann> hi, who all here today
09:00:19 <masayukig> o/
09:00:35 <chandankumar> \o/
09:00:53 <tosky> o/
09:01:20 <martinkopec> o/
09:01:30 <andreaf> o/
09:01:55 <gmann> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_6th_2017_.280900_UTC.29
09:02:02 <gmann> ^^ today agenda
09:02:28 <gmann> #topic Previous Meeting Action review
09:02:55 <gmann> saw 3 sessions andreaf proposed on forum
09:02:56 <andreaf> I proposed three different sessions for the forum
09:03:04 <gmann> andreaf: yea thanks
09:03:26 <gmann> andreaf: whats next on that, TC will select those ?
09:04:32 <gmann> #link http://forumtopics.openstack.org/cfp/details/111  http://forumtopics.openstack.org/cfp/details/112   http://forumtopics.openstack.org/cfp/details/113
09:04:44 <andreaf> gmann: yeah they're going to be reviewed - but how exactly I don't know tbh - I will check what the process is for sake of completion
09:05:04 <andreaf> gmann: I'm pretty sure we don't get to vote though
09:05:35 <gmann> heh, yea, let's wait for final selection. hope we get max :)
09:05:49 <gmann> #topic The Forum, Boston
09:06:02 <gmann> #link https://etherpad.openstack.org/p/BOS-QA-onboarding
09:06:29 <gmann> this is same, onboard sessions, put more ideas if anyone have
09:06:53 <andreaf> yeah there is still some time for that but we should be prepared
09:07:15 <andreaf> I guess everyone in the volunteer section below is going to be in Boston?
09:07:24 <gmann> yea, and hope we have max strength as presence
09:07:44 * masayukig nods
09:07:51 <gmann> hope so, i still need to get flight booking though
09:08:33 <gmann> #link Gate Stability - status update
09:08:56 <gmann> saw some pike on gate pipeline on neutron ssh one
09:09:23 <gmann> #link https://goo.gl/ptPgEw
09:09:49 <gmann> #link http://status.openstack.org/openstack-health/#/
09:10:19 <gmann> failure seems negative tests on o-h
09:10:26 <jordanP> there's one interesting patch being discussed atm on the ML
09:10:28 <jordanP> #link https://review.openstack.org/#/c/451492/
09:10:59 <jordanP> would be great if you guys, especially andreaf, would have a look at it
09:11:04 <gmann> jordanP: thanks
09:11:22 <jordanP> it's an important one, because it asks the question of "what distro/hybrid distro do we test"
09:11:59 <andreaf> jordanP: yes I've seen the ML thread - I will definitely review the patch
09:12:13 <jordanP> our libvirt version is old, newer version might have fewer memory corruption issues
09:12:28 <jordanP> the patch is about testing newer version of libvirt in the Gate
09:12:38 <gmann> let's see libvirt 2.5.0 have some good fix there
09:12:42 <gmann> yea
09:12:48 <andreaf> jordanP: possibly yes, the main idea is that we will get support from the libvirt community if we use a recent version :)
09:12:54 <jordanP> in other words, stop testing Ubuntu LTS, but test TLS + UCA packages
09:13:07 <jordanP> yes
09:13:18 <andreaf> jordanP: yeah the idea with LTS was to avoid impossible backports
09:13:36 <andreaf> jordanP: but UCA packages have been already tested by canonical in that sense
09:13:41 <gmann> will UCA packages be stable always?
09:13:44 <andreaf> jordanP: so they should be a valid option
09:13:49 <jordanP> yeah, I agree we should use UCA
09:14:04 <jordanP> i remember when I used to "manage" a cloud, we used UCA back in the days
09:14:15 <prateek> i have seen nova doing something like minimum libvirt version required, maybe we can try doing that in tempest too
09:14:54 <jordanP> Tempest is kinda black box testing, we don't even require libvirt
09:14:56 <gmann> prateek: on nova side it feature dependence etc
09:14:57 <andreaf> prateek: I'm not sure there is a dependency to libvirt in Tempest?
09:15:13 <gmann> yea, we should not make in tempsest
09:15:33 <prateek> andreaf, no there is not but i get the idea that we are having problems with a particular version of libvirt
09:15:54 <prateek> so we can have a constructor which allows us to skip tempest tests on that particular rogue versions
09:16:13 <andreaf> prateek yeah but tempest is there to detect those issues - it's not like we can say that there are specific tests that we can skip with wrong libvirt version
09:16:23 <prateek> andreaf, ok
09:17:09 <andreaf> prateek: failures are kind of random - at least we don't have a clear reproduce now and I doubt we can pinpoint any specific test in tempest
09:17:19 <gmann> andreaf: jordanP anything more we need to do on tests separation ? or we monitor gate status with lot of approaches going in
09:17:46 <jordanP> tests separation ?
09:18:06 <gmann> like separating scenario tests on separate jobs
09:18:12 <prateek> adreaf, got it, thanks :)
09:18:33 <jordanP> ah, I see, hum nothing that comes into my mind right now
09:19:03 <jordanP> (as usual, please do take into consideration the overall runtime of our jobs when enabling new scenarios/adding new tests)
09:19:12 <gmann> yea.
09:19:13 <jordanP> (1h20min is already very long)
09:19:45 <jordanP> one last patch that I'd like to see going through is https://review.openstack.org/#/c/450207/
09:19:46 <jordanP> #link https://review.openstack.org/#/c/450207/
09:19:47 <gmann> i am sure we do lot of duplicate operation tests mainly on API tests
09:20:03 <gmann> but that can be hard to fix due to lot of affort and mainly defcore
09:20:10 <jordanP> that patch is about disabling some not-so-needed Swift services in the Gate
09:20:27 <andreaf> thanks jordanP yeah that's a good one
09:20:49 <jordanP> yeah, we do have a lot of duplication/duplicated tests, so before approving any new test, we should make sure that this is not already tested somehow
09:20:52 <gmann> yea make sense
09:22:05 <gmann> thanks andreaf jordanP sdague, clarkb mtreinish ands everyone making so much effort on gate stability
09:22:12 <gmann> #topic Specs Reviews
09:22:21 <gmann> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
09:22:47 <gmann> new one was #link https://review.openstack.org/#/c/449295/
09:22:57 <gmann> Upgrade testing toolset
09:23:22 <gmann> castulo: sent mail also, i did not get chance to read yet
09:23:25 <andreaf> yea I think that  one deserves some more reviews
09:24:25 <gmann> yea
09:24:56 <gmann> anything else on spec ?
09:25:27 <gmann> #topic Tempest
09:25:31 <gmann> #link https://review.openstack.org/#/q/project:openstack/tempest+status:open
09:25:39 <gmann> ^^ current open reviews
09:26:22 <andreaf> I've submitted the goal ack for py35
09:26:22 <gmann> andreaf: jordanP can you re check this - https://review.openstack.org/#/c/419776/
09:26:36 <gmann> use case is in bug
09:27:05 <gmann> andreaf: thanks, so that is just for unit tests right. not as tempest on py35
09:27:12 <jordanP> I don't like that patch, too specific, but we can discuss it in #qa
09:27:25 <gmann> sure
09:28:17 <andreaf> gmann: #link https://review.openstack.org/#/q/topic:qa_py35_ack -  not even just adding py35 in setup.cfg
09:28:27 <gmann> andreaf: and we have done for both goal, wsgi and py35 right? or any help you need on either side?
09:28:45 <andreaf> gmann: not really I just wanted to let you know
09:28:59 <gmann> nice
09:29:46 <masayukig> how about py36? next step?
09:30:17 <gmann> masayukig: still not on tc side right but good to do that
09:30:31 <andreaf> masayukig: heh I think we can do py36 if we have time, the goal for Pike in 3.5 and I think there may be more urgent things
09:30:31 <masayukig> ok
09:30:48 <masayukig> sure
09:31:11 <gmann> on Bug Triage:
09:31:22 <gmann> i had this week
09:31:46 <gmann> #link https://etherpad.openstack.org/p/tempest-weekly-bug-report
09:32:04 <gmann> few new triaged and cleanup on old one.
09:32:22 <gmann> overall we have 4 new
09:33:14 <gmann> for many of the old bugs i saw patches but not reviewed actively so they are stuck in-progress
09:33:42 <gmann> we should start reviewing the old patches, some of them are nice to fix
09:34:48 <gmann> next week we have chandankumar turn
09:34:49 <gmann> #link https://etherpad.openstack.org/p/pike-qa-bug-triage
09:35:22 <masayukig> gmann : yeah, but I think most of old patches are out of date, so rebasing is required.
09:35:44 <gmann> masayukig: yea and author does not seems to active for many
09:35:47 <chandankumar> gmann: how much old patches they are ?
09:35:57 <gmann> masayukig: i pick some imp one and do myself
09:35:59 <jordanP> if the patch is stuck 'in progress' for a long time, maybe it means that it's not really a bug or it's not that important to fix
09:36:32 <masayukig> gmann : sounds nice
09:36:32 <gmann> chandankumar: well there are many, few cases with abandon patch and more with in-progress
09:36:47 <masayukig> jordanP: heh, maybe
09:36:59 <gmann> jordanP: humm may be but sometime people give up :)
09:37:36 <jordanP> sure, they give up because it's not their priority, because of time etc.
09:37:47 <gmann> mainly i want to cleanup the in-progress bugs
09:37:51 <jordanP> yeah
09:38:06 <masayukig[m]> ++
09:38:10 <gmann> either we abandon those patches and open bugs for new assignee or merge them
09:38:15 <chandankumar> gmann: i will take a look at in-progess ones this time
09:38:49 <gmann> chandankumar: thanks. please do ask author if they do not want to work so that anyone else can do
09:38:58 <gmann> #topic Patrole
09:39:00 <chandankumar> gmann: sure,
09:39:57 <gmann> any patrole guys here, sorry cannot find the irc name right now
09:41:01 <gmann> ok, only thing i have on patrole is that still i do not know why admin needed on each tests
09:41:15 <gmann> but i have to check framework more deeply
09:41:43 <gmann> #topic DevStack
09:42:15 <gmann> any more updates on devstack side apart jordanP pointed out about patches
09:42:47 <andreaf> I guess you have see the updates in the ML from sdague?
09:43:35 <andreaf> #link http://lists.openstack.org/pipermail/openstack-dev/2017-April/115039.html devstack systemd
09:43:39 <gmann> yea that was nice actually
09:43:42 <gmann> systemd
09:44:40 <gmann> nice one #link https://dague.net/2017/03/30/in-praise-of-systemd/
09:44:59 <andreaf> #link https://dague.net/2017/03/30/in-praise-of-systemd/ nice one
09:45:24 <gmann> yea
09:46:14 <gmann> i can get rid of moving myself over lot of screen
09:46:40 <gmann> ok. anything else or we move next
09:46:55 <gmann> #topic OpenStack-Health, Stackviz
09:46:58 <gmann> masayukig: ^^
09:47:07 <masayukig[m]> k
09:47:50 <andreaf> jordanP: did you look any further into getting more statsd data into stackviz?
09:47:59 <masayukig[m]> stackviz, I updated one patch for dstat graph improvement
09:48:03 <masayukig[m]> #link https://review.openstack.org/442253
09:48:08 <jordanP> andreaf, we have enough data, now we need to graph them
09:48:33 <andreaf> jordanP: heh yeah that's what I meant
09:48:48 <jordanP> yeah, so, no I'havent tried
09:49:14 <masayukig[m]> and regarding to openstack-health,
09:49:16 <jordanP> I don't know Javascript and I am bad at any frontend stuff
09:49:26 <masayukig[m]> heh
09:49:34 <gmann> we have masayukig :)
09:49:58 <masayukig[m]> I'm bad, too
09:49:59 <andreaf> masayukig[m] so is stackviz installed from source in the gate? if I do a patch in tempest with depends on will I be able to see the changes?
09:50:39 <masayukig[m]> andreaf: yeah, it sould be
09:50:55 <masayukig[m]> like this http://logs.openstack.org/28/384528/9/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/920f2e7/logs/stackviz/#/stdin/timeline
09:51:18 <masayukig[m]> a
09:51:40 <masayukig[m]> ah, sorry
09:51:47 <masayukig[m]> I'm not sure that
09:52:14 <masayukig[m]> but I think it's worth to try :)
09:52:18 <gmann> i think we do from source but not 100% sure
09:52:22 <jordanP> humm I don't see whhat/where is stackviz installed
09:53:06 <jordanP> sudo pip install -U $stackviz_path
09:53:11 <masayukig[m]> it's only written in frontend javascript
09:53:34 <andreaf> uhm pip install won't work
09:53:49 <andreaf> unless that's a file system path :)
09:53:53 <masayukig[m]> jordanP: heh, I actually didn't use pip install
09:53:57 <jordanP> yeah, it's a path
09:54:01 <gmann> yea #link http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n584
09:54:10 <andreaf> #link https://review.openstack.org/#/c/454078/ testing stackviz
09:54:55 <gmann> ok
09:55:02 <gmann> 5 min left
09:55:05 <masayukig[m]> so, regarding to openstack-health, mtreinish and I approved two openstack-health api server patches, but the api server has nothing to change.
09:55:30 <masayukig[m]> does anyone know the mechanizm of that?
09:56:12 <gmann> did not get you approved patches but did not reflect on api server side?
09:56:30 <jordanP> don't you need to redeploy something ?
09:56:47 <masayukig[m]> jordanP: it's automatically
09:56:53 <jordanP> automagic :)
09:56:55 <andreaf> masayukig[m]: puppet should pick it up automagically - it's in continuous deploy afaik
09:57:08 <masayukig[m]> andreaf: yeah, I read https://docs.openstack.org/infra/system-config/openstack-health.html
09:57:26 <andreaf> masayukig[m]: so look into the puppet module and ping infra if for checking into logs maybe something is going wrong
09:57:31 <andreaf> a dependency update or so
09:57:35 <masayukig[m]> So, I'd like to see the logs
09:57:47 <andreaf> or it may need a nudge
09:57:58 <gmann> EmilienM can help may be
09:58:03 <andreaf> masayukig[m]: on subunit2sql I think https://review.openstack.org/#/c/334556 could use more reviews
09:58:16 <andreaf> #link https://review.openstack.org/#/c/334556 for subunit2sql please reviews :)
09:58:40 <gmann> ok. lets move next
09:58:42 <gmann> #topic Destructive Testing
09:58:48 <masayukig[m]> andreaf: ah, yeah,
09:59:00 <gmann> did not see spec updated from samP
09:59:05 <masayukig[m]> andreaf: I'll do it tomorrow :)
09:59:10 <gmann> #topic Critical Reviews
09:59:31 <gmann> i have this one, did rebase many times - https://review.openstack.org/#/c/438006/
09:59:43 <andreaf> #link https://review.openstack.org/#/c/451769/ not so critical but it could use more opinions
09:59:54 <gmann> sure
10:00:08 <gmann> we are out of time, let's move to qa if more discussion needed
10:00:14 <gmann> thanks everyone for joining
10:00:18 <gmann> #endmeeting