09:00:05 <oomichi> #startmeeting qa
09:00:06 <openstack> Meeting started Thu Nov 12 09:00:05 2015 UTC and is due to finish in 60 minutes.  The chair is oomichi. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:09 <openstack> The meeting name has been set to 'qa'
09:00:17 <oomichi> who's here for today's meeting
09:00:22 <andreaf> o/
09:00:30 <dmellado> o/
09:00:31 <gmann> o/
09:00:56 <oomichi> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_November_12th_2015_.280900_UTC.29
09:01:02 <oomichi> ^^^ today agenda
09:01:12 <oomichi> Ok, let's get started
09:01:34 <oomichi> #topic Mitaka Sumit: Summarize
09:01:53 <oomichi> we had Tokyo summit and we need to summarize it as conclusion
09:02:08 <dmellado> hey oomichi it was me who proposed that as I couldn't attend the mitaka summit and wanted to get to know the main action points ;)
09:02:14 <oomichi> but to be honest, I saw this agenda item at this time :(
09:02:28 <oomichi> and I forgot the link of mitaka prio etherpad
09:02:56 <oomichi> dmellado: hey, I am serching this
09:03:02 <andreaf> #link https://etherpad.openstack.org/p/mitaka-qa-priorities
09:03:04 <dmellado> https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#QA
09:03:06 <dmellado> ?
09:03:15 <oomichi> andreaf: thanks ! :-)
09:03:37 <gmann> yea in that we have conclusion and target dates
09:03:50 <oomichi> As the etherpad, we have conclusion
09:03:54 <oomichi> gmann: yeah
09:03:57 <dmellado> oomichi: awesome
09:04:09 <andreaf> oomichi, dmellado: I guess we could have a message in the ML like other projects did - but I'd say that's something for mtreinish if he wants to :)
09:04:11 <oomichi> the target date is closed on some items
09:04:30 <dmellado> andreaf: sounds fine for me
09:04:37 <oomichi> andreaf: yeah, nice idea
09:04:47 <oomichi> andreaf: mtreinish didn't it yet?
09:05:04 <oomichi> I don't see it now
09:05:32 <gmann> yea, on ML it is not yet
09:05:39 <oomichi> ok
09:05:43 <oomichi> #action mtreinish will send a mail of tokyo summit conclusion -dev ml
09:05:50 <oomichi> how about ^^^ ?
09:05:56 <dmellado> +1
09:06:03 <gmann> yea
09:06:37 <oomichi> ok, will ask him. maybe he will know it by this log :)
09:07:18 <oomichi> to be honest, microversion test is a little close
09:07:31 <oomichi> and we need to get +A on the spec
09:07:41 <oomichi> but I will talk about this later
09:07:47 <dmellado> oomichi: I can lend a hand on that if you're tigh on schedule
09:08:18 <oomichi> dmellado: thanks :-) ok, let's talk about this later :)
09:08:22 <dmellado> sure
09:09:02 <oomichi> the mail will be very important for tracking our aciton items
09:09:29 <oomichi> can we move to the next topic?
09:09:39 <dmellado> fine for me
09:09:41 <gmann> yea
09:09:48 <oomichi> thanks
09:09:50 <oomichi> #topic Specs Reviews
09:10:01 <oomichi> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
09:10:35 <oomichi> some available specs are updated
09:11:18 <oomichi> gmann: can we talk about microversion testing?
09:11:23 <gmann> oomichi: yea
09:11:29 <oomichi> gmann: that is the first spec on the list
09:11:33 <gmann> oomichi: as you mentioned spec is close to merge
09:11:35 <gmann> #link https://review.openstack.org/#/c/169126/12
09:11:48 <jordanP> hi. (sorry I'm late...)
09:11:55 <dmellado> hi jordanP ;)
09:12:00 <oomichi> jordanP: hi :-)
09:12:03 <gmann> i was thinking about updating ref there for base patch
09:12:16 <gmann> oomichi: what do you think?
09:12:21 <gmann> or leave as it is
09:12:33 <oomichi> gmann: that means not spec patch?
09:12:47 <oomichi> gmann: base patch means tempest patch instead
09:13:31 <gmann> oomichi: in spec, there is comment about having base patch as reference to understand the spec clearly
09:13:44 <gmann> oomichi: yea Tempest patch as POC
09:13:51 <oomichi> gmann: ah, nice to do that
09:14:04 <gmann> oomichi: ok will update after meeting
09:14:14 <oomichi> gmann: cool, thanks :-)
09:14:28 <gmann> so after that it should be fine to merge soon :)
09:14:43 <oomichi> gmann: yeah, we can do that later
09:15:08 <oomichi> andreaf: your resource spec is there on the list
09:15:46 <oomichi> andreaf: do you have comments on that?
09:15:49 <andreaf> oomichi: yes I updated the spec after the session in Tokyo - it would be great to get reviews on it
09:16:19 <oomichi> andreaf: thanks for doing that, unnecessary spaces at line 102: NIT ;-)
09:16:41 <andreaf> oomichi: ok I will re-spin it once I get more comments :)
09:16:44 <gmann> andreaf: yea, ll try to review it tomorrow.
09:16:52 <andreaf> thanks
09:16:57 <oomichi> andreaf: yeah, will review it soon. that is good for production testing
09:17:31 <oomichi> maybe we can move the next topic
09:17:55 <oomichi> #topic Tempest
09:18:14 <oomichi> dmellado: the first is yours. can you ;-)
09:18:33 <dmellado> sure ;)
09:19:05 <oomichi> dmellado: can you introduce it?
09:19:09 <dmellado> There's this script that we've been using in order to get a tempest.conf file
09:19:26 <dmellado> who was initialy written by dkranz
09:19:41 <dmellado> and I think that it'd be a nice tool to have upstream in order to configure tempest not only against devstack
09:19:48 <dmellado> but for any cloud too
09:19:54 <dmellado> https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py
09:20:08 <oomichi> #link https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py
09:20:12 <dmellado> I was speaking with jordanP about this and he suggested creating also some functional tests for it
09:20:42 <oomichi> dmellado: what kind of functional tests?
09:20:55 <dmellado> what do you think about the idea?
09:20:58 <dmellado> (and what would you suggest about the steps to do so)
09:21:24 <dmellado> oomichi: jordanP suggested something in the lines of comparing the tempest.conf file generated by devstack with one created by this tool
09:21:36 <dmellado> but I'm all open to suggestions
09:21:44 <oomichi> dmellado: ah, I see.
09:22:05 <oomichi> dmellado: but what is the main difference between devstack and this scirpt?
09:22:11 <andreaf> dmellado: does this tool create test resources, or it discovers them or both?
09:22:18 <jordanP> or run "verify_tempest_config.py" on that file
09:22:21 <andreaf> oh, sorry
09:22:27 <gmann> somewhere did we talk about generating the conf using tempest CLI ? m do not remember exactly
09:22:35 <dmellado> well, basically this script can be used to create a tempest.conf file aganinst any cloud
09:22:37 <dmellado> and not only devstack
09:22:49 <dmellado> it can also create the resources, if needed
09:23:02 <gmann> andreaf: both, like it create flavor etc if there is no
09:23:18 <gmann> #link https://github.com/redhat-openstack/tempest/blob/rebased-upstream/tools/config_tempest.py#L520
09:23:32 <oomichi> dmellado: that means the script gets extensions' list via REST API and generates the conf?
09:23:46 <gmann> andreaf: do you remember to have CLI to generate conf like that ?
09:23:46 <dmellado> oomichi: exactly
09:23:49 <oomichi> dmellado: based on the available extensions/features
09:24:04 <dmellado> I'm reviewing it myself but it'll be a nice additions
09:24:09 <gmann> may be we can use there
09:24:21 <ylobankov> dmellado: Rally can generate tempest.conf as well
09:24:27 <oomichi> dmellado: we tried to do that before in tempest, but the idea was denied by sdague and mtreinish
09:24:40 <boris-42> oomichi: that was bad=(
09:24:40 <dmellado> like the cleanup script and so on
09:24:40 <dmellado> maybe we can integrate them all with the cli...
09:24:44 <boris-42> oomichi: we have spec for that
09:24:50 <oomichi> because if the detecting feature contains a bug, most tests will be skipped
09:24:55 <dmellado> as gmann said
09:25:18 <dmellado> oomichi: why?
09:25:24 <dmellado> just read
09:25:35 <oomichi> basically, we need to understand what tests will run against the clouds
09:25:36 <andreaf> dmellado, gmann, oomichi, boris-42: I'm not against having the script, but I would not use in the gate the discovery part
09:25:52 <dmellado> andreaf: my usecase wouldn't be in the gate
09:25:55 <andreaf> discovery is a bad idea, it's better to configure what we expect to have
09:25:57 <dmellado> but as a tool for tempest
09:26:16 <dmellado> it can also accept a set of options to override
09:26:17 <oomichi> dmellado: if the script misunderstands there is not available extensions on the cloud, the corresponding tests are skipped
09:26:21 <jordanP> a first step would be to add this script in Tempest repo, add some tests around it. No use it directly for the gate.
09:26:29 <gmann> yea on gate discovery much more risky
09:26:41 <andreaf> because if you disable something by mistake, or if discovery is broken, you will stop testing things and not even realise
09:26:55 <oomichi> andreaf: exactly
09:26:57 <gmann> andreaf: exactly
09:27:06 <oomichi> gmann: conflict :)
09:27:12 <dmellado> then I'll create some tests and add the script as a "feature" for using it
09:27:35 <dmellado> if it sounds ok for all of you guys ;)
09:27:40 <gmann> if during cloud upgrade some extensions got broken then tempest would be able to catch those
09:27:59 <andreaf> however the part that generates the resources or the accounts file could be used, and perhaps replace devstack implementation of it
09:28:04 <gmann> would -> would not
09:28:28 <dmellado> andreaf: actually I was thinking about getting rid of that
09:28:48 <oomichi> dmellado: basically, I can understand this feature because OpenStack has a lot of APIs and it is difficult to set up Tempest by hands
09:28:50 <dmellado> and just rely on accounts.yaml script
09:28:51 <jordanP> guys, for now it's just a tool that can be useful to some, we have a folder called tools in tempest
09:29:06 <dmellado> jordanP: that was my intended path
09:29:35 <oomichi> it is better to discuss it on the ml for getting opinions before having it on tempest
09:29:48 <andreaf> jordanP: sure, but it can be useful for people if it works, and to keep it working it's best if we can exercise it
09:29:51 <oomichi> because pre-PTL and PTL are against it
09:30:04 <jordanP> andreaf, exactly. That's why I asked to add tests
09:30:33 <jordanP> maybe a non voting job, or some unit tests (I'd rather have functional tests than units)
09:30:43 <oomichi> or how about proposing the spec?
09:30:45 <jordanP> but let's agree on the idea first
09:30:48 <dmellado> oomichi: andreaf how about having it added to the tools folders with some tests after removing the create part
09:31:04 <jordanP> a spec for something that is already here, I am not sure
09:31:18 <jordanP> dmellado, let's raise the issue on the ML
09:31:33 <dmellado> I'll send an email
09:31:35 <gmann> jordanP: it was there. but good to first get agreement on ML before spec
09:31:40 <oomichi> dmellado: thanks:)
09:31:50 <gmann> dmellado: Thanks.
09:32:07 <oomichi> #action dmellado will send a mail about auto-genenating conf script to -dev ml.
09:32:07 <dmellado> np, let's see what the feedback is and let's agree on its usecase
09:32:26 <oomichi> dmellado: thanks again
09:32:30 <dmellado> np oomichi
09:32:31 <gmann> #link https://review.openstack.org/#/c/94473/
09:32:36 <gmann> previous spec for the same
09:33:03 <dmellado> should we revisit the spec?
09:33:12 <oomichi> gmann: nice point
09:33:23 <oomichi> dmellado: it is nice to propose the other spec
09:33:23 <gmann> dmellado: i would suggest after ML conclusion
09:33:41 <dmellado> +1 on that
09:34:27 <oomichi> I'd like to move the next item
09:34:34 <oomichi> the next item is mine
09:34:42 <oomichi> that is Service clients
09:34:52 <oomichi> #link  https://etherpad.openstack.org/p/mitaka-tempest-service-clients
09:35:12 <oomichi> I created an etherpad ^^^ for managing this
09:35:32 <oomichi> and we need to create a lot of patches for that before M-2
09:36:02 <oomichi> please write your names as Assignees if interested in ;)
09:36:30 <oomichi> my mistake was I decided the deadline is M-2 anyways
09:36:48 <jordanP> oomichi, so bold of you  ! :)
09:36:54 <dmellado> lol
09:37:06 <gmann> heh
09:37:10 <jordanP> I can help starting in 10 days, I have a lot to do right know
09:37:25 <jordanP> I still think it's doable
09:37:26 <oomichi> jordanP: mtreinish denied to change the deadline
09:37:35 <jordanP> oomichi, I don't remember that !
09:37:46 <jordanP> :D
09:37:48 <oomichi> so we need to implemet them before !
09:37:58 <oomichi> jordanP: thanks ;-)
09:38:08 <andreaf> oomichi: I'm trying to get volunteers to help on that - if we had a stable set of clients by M2 in tempest-lib it would be great
09:38:18 <dmellado> oomichi: would your script still work for those? xD
09:38:32 <oomichi> andreaf: thanks ! :)
09:38:45 <oomichi> dmellado: yes, that should work
09:38:49 <jordanP> here, I committed on tempest/services/volume/json/*.py
09:38:51 <gmann> oomichi: after microversion i can also help
09:38:59 <dmellado> then I can take some of those too
09:39:34 <oomichi> jordanP: did you post the patches?
09:39:38 <dmellado> oomichi: I'll ping you after the meeting for this
09:39:55 <oomichi> dmellado: yeah, lets talk about it later
09:40:02 <oomichi> gmann: thank you also
09:40:15 <jordanP> oomichi, no. I just added my  name in the etherpad
09:40:20 <jordanP> not 'git commit'
09:40:32 <oomichi> jordanP: thanks much!
09:40:58 <oomichi> ok, I can get many people
09:41:15 <oomichi> lets move to the next item
09:41:24 <oomichi> gmann: can you introduce API microversions testing?
09:41:33 <gmann> oomichi:  sure
09:41:45 <oomichi> gmann: thanks
09:41:53 <gmann> as discussed early, spec is almost in
09:42:03 <gmann> and in parallel there are base patches out
09:42:06 <gmann> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/nova-microversions-tests,n,z
09:42:36 <gmann> currently m implementing microversion for Nova v2.2 microversion to tests the base framework
09:42:47 <gmann> might be able to do by tomorrow
09:42:54 <oomichi> gmann: cool, does it work now?
09:43:06 <gmann> early feedback is nice if all can review those base patches
09:43:09 <oomichi> gmann: ah, I see.
09:43:24 <gmann> oomichi: not yet completed, still doing version of schema for v2.2
09:43:35 <oomichi> gmann: nice progress
09:44:02 <gmann> oomichi: as mentioned in spec, once framework is tested well then we can think to move that in lib
09:44:12 <gmann> deadline is M-1 :)
09:44:22 <oomichi> gmann: yeah, too close
09:44:33 <oomichi> gmann: but it is available since current progress
09:44:55 <oomichi> gmann: it is enough to implement v2.2 test only before M1
09:45:02 <gmann> oomichi: thinks so. lets see
09:45:17 <gmann> oomichi: yea so that we can tests the framework on gate
09:45:44 <oomichi> gmann: cool, I see
09:45:50 <oomichi> gmann: I will review them later
09:45:56 <gmann> oomichi: Thanks
09:46:10 * oomichi having AIs after meeting
09:46:27 <oomichi> #action oomichi will review microversion tests patches
09:46:38 <gmann> thats all on microversion testing
09:46:51 <oomichi> gmann: thanks
09:47:02 <oomichi> lets move to the next topic
09:47:22 <oomichi> we can skip devstack and grenade, maybe as every meeting
09:47:36 <oomichi> #topic OpenStack Health
09:47:47 <oomichi> #link      https://etherpad.openstack.org/p/openstack-health-tracking
09:48:17 <oomichi> can someone talk about this?
09:48:37 <andreaf> I don't have a very consistent update to provide here, is anyone around who can talk about this else I'll do my best
09:48:52 <dmellado> is glauco around? I don't think so
09:49:02 <andreaf> dmellado: no probably not
09:49:17 <oomichi> andreaf: could you ?
09:49:25 <andreaf> dmellado: well o-h is not integrated in the OpenStack css
09:49:41 <dmellado> andreaf: wasn't that a WIP?
09:50:21 <andreaf> dmellado: yes probably, but at least now the page headers and footers are maintained when browsing through o-h
09:50:46 <andreaf> work is still in progress to make performance improvements for the test view
09:51:01 <oomichi> #link http://status.openstack.org/openstack-health/#/
09:51:08 <jordanP> http://health.openstack.org/ doesn't look right :)
09:51:16 <oomichi> that seems nice now
09:51:36 <oomichi> really easy to know current situation :)
09:52:08 <andreaf> and there is one feature that would be a great usability improvement, which is data grouping by arbitrary run metadata key
09:52:22 <andreaf> but that requires some normalisation of the rest API first
09:53:05 <andreaf> the routes of the rest API have been growing rather organically, so we need a bit of rework there
09:53:19 <oomichi> andreaf: what kind of normalisation?
09:53:50 <oomichi> andreaf: do we need to implement microversion on o-h also? ;)
09:54:10 <jordanP> :p
09:54:36 <andreaf> oomichi: I think the main issue is the we now have /projects , where project is a specific metadata key, and we need to support /<metadata-key> instead
09:55:18 <oomichi> andreaf: that seems nice direction
09:55:41 <andreaf> oomichi: I know mtreinish does not want the API to be tightly coupled to the UI workflow (page 1 to 4), but tbh I don't have all the right details here to provide a proper update on this point
09:56:24 <oomichi> andreaf: yeah, it is so fast step to do that on o-h
09:57:04 <oomichi> andreaf: thanks for providing
09:57:19 <oomichi> ok, lets move to the next topic
09:57:27 <oomichi> #topic Critical Reviews
09:57:38 <oomichi> do we have any critical patches for reviewing
09:57:41 <oomichi> ?
09:58:29 * oomichi masayukig introduce o-h for japanese users on http://thinkit.co.jp/story/2015/11/10/6594
09:58:51 <gmann> cool
09:59:34 <gmann> cool pic there :)
09:59:51 <oomichi> I had https://review.openstack.org/#/c/168762/ but andreaf already -1 :p
10:00:04 <andreaf> oomichi: also periodic-qa and periodic-stable are part of the collected data now
10:00:42 <oomichi> oh, time comes
10:00:44 <oomichi> thanks all
10:00:48 <gmann> Thanks all
10:00:48 <oomichi> #endmeeting