17:00:06 <oomichi> #startmeeting qa
17:00:07 <openstack> Meeting started Thu Apr 14 17:00:06 2016 UTC and is due to finish in 60 minutes.  The chair is oomichi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:11 <openstack> The meeting name has been set to 'qa'
17:00:17 <oomichi> hi, who's here today?
17:00:30 <sdague> o/
17:00:40 <fnaval> o/
17:00:41 <mtreinish> hi
17:00:49 <oomichi> sdague: fnaval: mtreinish: hi
17:01:07 <ylobankov> hi! sorry for a long absence. was on vacation
17:01:19 <fnaval> hello - i haven't attended in a long time; getting a feel of the state of Openstack QA now
17:01:26 <oomichi> ylobankov: hi, no worry :-)
17:01:52 <oomichi> ok, lets start
17:02:05 <oomichi> #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_14th_2016_.281700_UTC.29
17:02:11 <oomichi> ^^^ today agenda
17:02:24 <oomichi> #topic Specs Reviews
17:02:33 <oomichi> #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
17:02:53 <oomichi> there are several specs on the gerrit
17:03:01 <oomichi> and most ones are red.
17:03:21 <oomichi> we need to update them as comments if wanting to approve
17:03:45 <oomichi> mine is the first, but it needs more time
17:03:53 <oomichi> that sould be WIP
17:04:18 <mtreinish> oomichi: which one is that?
17:04:18 <oomichi> someone have a spec if picking it up now?
17:04:29 <oomichi> mtreinish: swagger one: https://review.openstack.org/#/c/297473
17:04:39 <oomichi> I am done as WIP
17:04:40 <hogepodge> o/
17:04:45 <oomichi> hogepodge: hi
17:05:01 <oomichi> at requires more considering
17:05:07 <oomichi> s/at/that/
17:05:20 <luzC> o/
17:05:30 <oomichi> luzC: hi
17:05:33 <sdague> oomichi: I think the swagger spec assumed that swagger could be used in parts, instead of needing to be used as a whole
17:06:17 <oomichi> sdague: yeah, that can make confusions
17:06:43 <oomichi> sdague: we need a big picture how to implement/create whole swagger at the first step
17:06:49 <sdague> I do understand the desire to use some structured standard, but we have to remember when doing that that we have to be 100% conformant to such standard, otherwise it's not useful
17:07:00 <sdague> and potentially damaging
17:07:08 <jlvillal> o/
17:07:33 <oomichi> sdague: yeah, I agree
17:08:28 <oomichi> sdague: I am creating the picture how to combine these data for whole swagger. I am stopping qa swagger-spec until it done
17:09:12 <sdague> oomichi: ok. I'm not sure it's really worth the time right now though. There are a lot of more concrete things to make life better.
17:09:43 <oomichi> sdague: yeah, that is long-time goal
17:09:55 <oomichi> sdague: nice to do more actual merit thing
17:10:01 <oomichi> sdague: that is just PoC
17:10:11 <oomichi> as my hobby :)
17:10:32 <oomichi> can we move to the next topic?
17:10:46 <sdague> yes
17:10:50 <oomichi> if not having more items about qa-spec
17:11:03 <oomichi> ok, let's move on
17:11:14 <oomichi> #topic Tempest
17:11:44 <oomichi> #link https://review.openstack.org/#/q/project:openstack/tempest+status:open
17:11:47 <dstanek> o/ better late than never
17:12:04 <oomichi> there are a lot of patches on the review
17:12:24 <oomichi> and most patches seem to be reviewing
17:12:31 <oomichi> that seems a good progress
17:13:05 <oomichi> I don't have special patches for picking them up here
17:13:33 <oomichi> anyone have patches or idea for picking up here?
17:13:48 <mtreinish> I was wondering when adding nova microversion tests, should we update the schema in a separate patch or keep it with the test?
17:14:00 <mtreinish> I'm thinking we want it to be self testing so it should be all in 1 patch
17:14:12 <mtreinish> #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/virt-device-role-tagging
17:14:18 <mtreinish> that's what made me think about the topic
17:14:41 <oomichi> mtreinish: yeah, IMO it is nice to merge them in a single patch for verifying the schema
17:14:48 <oomichi> with the gate test.
17:15:28 <sdague> it would be nice if we could avoid https://review.openstack.org/#/c/305456/2/tempest/lib/api_schema/response/compute/v2_19/servers.py
17:15:28 <patchbot> sdague: patch 305456 - tempest - Update get server response schema
17:15:56 <sdague> the model of doing patching to our schemas makes it actually quite hard to see what the schema really is
17:16:30 <sdague> it would be nicer if those were exploded out, especially assuming a future where old stuff is actually deleted eventually
17:17:12 <oomichi> sdague: do you want to write all schema data for each microversion?
17:17:33 <sdague> yeh, I think so
17:17:41 <oomichi> sdague: that could be big and a little hard to know what difference between microversions
17:18:20 <sdague> they will be big, but they will let you evaluate what a particular resource looks like fully
17:18:55 <mtreinish> yeah I agree with sdague here, this is really hard to follow: https://github.com/openstack/tempest/blob/master/tempest/lib/api_schema/response/compute/v2_2/keypairs.py
17:18:58 <oomichi> I can see your point. current way is not so readable to know what is expected schema from human POV
17:19:12 <sdague> right, and the point of this code in tree is for humans to understand it
17:19:19 <sdague> we should optimize for humans
17:19:42 <sdague> and make a tool to generate schema diffs between versions if that's helpful to see
17:20:03 <oomichi> mtreinish: humm, yeah, nice sample
17:20:14 <sdague> mtreinish: right, keypairs is an excellent example. It would take someone quite a while to actually get that fully in their head
17:20:39 <oomichi> I see
17:20:40 <fnaval_> seeing it for the first time, I agree
17:21:14 <sdague> is there a reasonable way to include yaml files in the tempest resource package that we could reference as a resource? I remember mordred saying something about that in the past.
17:22:00 <mtreinish> sdague: like this spec: https://review.openstack.org/173334 ?
17:22:04 <oomichi> sdague: is that to convert json-schema to yaml files on tempest?
17:22:10 <mtreinish> or are you talking about something else?
17:22:31 <sdague> mtreinish: not that
17:22:44 <mtreinish> sdague: heh, it had all the buzzwords resources and yaml :)
17:23:02 <sdague> I think this https://pythonhosted.org/setuptools/pkg_resources.html
17:23:20 <sdague> basically that there would be yaml files that can be programatically accessed without config
17:23:28 <sdague> because the python package manages them
17:23:34 <sdague> oomichi: yeh, for json schema in files
17:23:43 <sdague> keystone is doing it in yaml, because it allows comments
17:23:45 <sdague> and it's very nice
17:24:24 <mtreinish> sdague: yeah, that's why we did python files so we could have comments and stuff. But I guess a big dict is still kinda ugly
17:24:44 <sdague> anyway, it's a little afar now, but the current jsonschema handling in nova / tempest ends up being pretty unreadable to anyone that's not super familiar with it
17:25:03 <sdague> which means very few people can understand the validation, which makes it error prone
17:25:35 <oomichi> sdague: yeah, nice to better way for many people
17:25:52 <oomichi> and the package idea is interesting for me
17:26:47 <oomichi> I d like to confirm one conclusion
17:27:05 <oomichi> is it fine to write all json-schema data for each microversion?
17:27:28 <oomichi> I agree with that for readability
17:27:44 <oomichi> or any objections here?
17:28:04 <mtreinish> oomichi: yeah I think it'll probably be better that way. So everything is there, the current model of inheritence with overwriting fields is really hard to figure out
17:28:14 <oomichi> if not, I will talk about it with gmann who is most active for this schema work
17:28:40 <oomichi> ok, will talk about it with gmann
17:29:05 <oomichi> #action oomichi talks about separation of json-schema for each microversion with gmann
17:29:22 <oomichi> do we have more topic about tempest here?
17:29:23 <sdague> oomichi: I agree with mtreinish
17:29:54 <oomichi> sdague: I see, thanks for pointing it up
17:30:09 <oomichi> ok, let's move on
17:30:21 <oomichi> #topic DevStack + Grenade
17:30:49 <oomichi> #link https://review.openstack.org/#/q/project:openstack-dev/devstack+status:open
17:31:15 <oomichi> there are many patches about devstack also
17:31:37 <oomichi> someone want to talk about devstack/grenade here?
17:32:22 <mtreinish> I don't have anything for this week
17:32:40 <oomichi> mtreinish: thanks. ok, let's move on
17:32:45 <mtreinish> we could always pester sc68cal about the neutron rewrite :)
17:32:57 <sdague> the only notable bits are the swift multinode code
17:33:04 <mtreinish> sdague: oh, that all landed?
17:33:08 <sdague> not yet
17:33:27 <sdague> https://review.openstack.org/#/c/304468/ is the devstack change needed
17:33:27 <patchbot> sdague: patch 304468 - openstack-dev/devstack - Add variable SWIFT_STORAGE_IPS
17:33:51 <sdague> then there is a bunch of d-g changes as well
17:34:00 <sdague> but it would be good to land that bit
17:34:19 * mtreinish looks
17:34:19 <notmyname> I'm catching up on cschwede's work on that. it's tracked on https://etherpad.openstack.org/p/swift-rolling-upgrade-multinode-testing
17:34:31 <notmyname> (the multinode, rolling upgrade testing for swift)
17:35:02 <notmyname> cschwede is the person to talk to (but it's nearly 8pm for him right now)
17:35:24 <sdague> notmyname: yep, he's been pretty responsive, I just +2ed the devstack patch he respun this morning
17:35:30 <notmyname> great, thanks
17:36:11 <oomichi> notmyname: are all necessary patches proposed already for testing?
17:36:48 <notmyname> oomichi: I don't know. I've been traveling this week, and I'm just catching up today
17:37:22 <oomichi> notmyname: ah, ok. I will check it later
17:38:15 <oomichi> can we move to the next topic if not having more about devstack/grenade
17:38:16 <sdague> oomichi: in the d-g patches I looked at this morning there is a bit of an order of operations mismatch with the way that multinode d-g assumes it can do things. I was going to try to catch cschwede in the morning to chat about possible options there that don't require tearing down the whole flow model in d-g
17:38:36 <sdague> oomichi: yeh, we can move on
17:39:11 <oomichi> sdague: Thanks for info
17:39:34 * oomichi needs more time later for understanding
17:39:42 <oomichi> #topic Austin Summit
17:40:08 <oomichi> #link https://etherpad.openstack.org/p/newton-qa-summit-topics
17:40:30 <oomichi> I am trying to push topics to available slots based on voting
17:40:52 <oomichi> and one slot remains now
17:41:05 <oomichi> at the last work room.
17:41:34 <mtreinish> oomichi: I don't think everyone pays attention to the interested section. I know I really didn't :)
17:42:12 <oomichi> mtreinish: humm, what is meaning?
17:42:34 <oomichi> is it difficult to understand the contents from the titles?
17:42:43 <mtreinish> I didn't bother saying which sessions I was interested in on the etherpad (except for the first day)
17:42:54 <mtreinish> I don't think it's a reliable voting system
17:43:32 <sdague> do we actually need the ceph session? I thought that was basically all solved
17:43:44 <mtreinish> sdague: you asked for it
17:43:45 <sdague> we're just waiting on clarkb to get the ceph package mirror working
17:43:47 <fnaval_> I updated the etherpad with  my nick for the sessions im interested in
17:43:53 <sdague> mtreinish: when did I ask for it?
17:44:01 <clarkb> sdague: my suggestion at this point would be for someone else to finish cleaning up that patch
17:44:09 <clarkb> bceause I keep getting pulled away to extinguish fires
17:44:30 <sdague> clarkb: what sort of access does such a person need to be able to test it reasonably?
17:44:34 <mtreinish> sdague: like a month ago? when we were talking about bring the ceph devstack plugin into qa
17:44:54 <clarkb> sdague: you just need to be able to run reprepro
17:44:54 <sdague> mtreinish: right, but I thought we basically built a plan and almost fully executed it already
17:45:10 <clarkb> sdague: then an infra root can handle the afs bits but that should be mostly transparetn because ext4 vs afs are similar enough in this case
17:45:46 <sdague> clarkb: ok
17:45:48 <mtreinish> sdague: I thought there were open questions, like do we bake the plugin back into tempest
17:46:00 <mtreinish> do we use ceph everywhere instead of lvm, etc
17:46:02 <sdague> mtreinish: you mean devstack?
17:46:05 <clarkb> and the change is mostly done, it has some small things that need fixing and maybe a rebase
17:46:23 <mtreinish> yeah, sorry devstack
17:46:47 <sdague> mtreinish: ok, that's fine if there are more topics. I just thought that we were mostly sorted.
17:47:03 <sdague> personally, I think a plugin is a better model
17:47:21 <mtreinish> I mean if we don't need the session great, it's not necessary. I definitely don't think it needs a fishbowl if we do have one
17:47:47 <sdague> yeh, I would put the more generic devstack one into the fishbowl over that one for sure
17:48:03 <sdague> and I'm not sure that it's really needed. Maybe make it a touch point on the friday meetup
17:48:43 <mtreinish> sdague: that works for me, although now our session gap is 2 workrooms :)
17:49:02 <oomichi> oh..
17:49:42 <mtreinish> oomichi: I updated the etherpad for you
17:49:46 <oomichi> ok, how about having code sprint type sessions instead?
17:49:51 <oomichi> mtreinish: thanks, I see
17:50:06 <oomichi> for work rooms
17:50:36 <mtreinish> oomichi: personally I don't think that'll work for me. I'm normally too busy and overworked during summit a code sprint doesn't work for me
17:50:57 <mtreinish> I wouldn't be able to concentrate on it (and I'll likely just go to a different session)
17:51:49 <oomichi> mtreinish: hum, yeah
17:52:36 <mtreinish> oomichi: we could do unsessions, where it's free form discussion. Or we can talk to ttx and give them to people who need the slot
17:52:36 <oomichi> but we cannot work actually in the summit, nice to have sessions for creating ptaches based on the discussion
17:53:02 <mtreinish> oomichi: what happened to the tempest resource tracker topic?
17:53:03 <hogepodge> This may not be the place to bring this up (I was waiting for the open discussion), but there are a few defcore related topics that will could have an impact on Tempest during the next cycle. I do want to talk with the Tempest team about some of these things during the Austin summit. It probably doesn't warrant a full session, though.
17:53:09 <oomichi> mtreinish: yeah, a nice idea if we don't have more idea now
17:53:19 <mtreinish> oomichi: also I feel like we should have a cli topic
17:53:34 <mtreinish> oomichi: and hogepodge just volunteered to run a defcore tempest session
17:53:43 <mtreinish> so there are 3 topics to fill 2 slots :)
17:53:54 <oomichi> mtreinish: I told about it with andreaf, and he said we don't have more topics we need to discuss at the summit
17:54:30 <mtreinish> oomichi: ok, then how about Tempest CLI and tempest x defcore
17:54:30 <oomichi> mtreinish: yeah, I asked CLIs thing with masayukig, and he also doesn't have more
17:54:42 <oomichi> hogepodge: yeah, nice idea. thanks
17:54:51 <oomichi> hogepodge: can you write it on the etherpad?
17:54:57 <hogepodge> oomichi: thank you, I will
17:54:58 <oomichi> hogepodge: https://etherpad.openstack.org/p/newton-qa-summit-topics
17:55:01 <oomichi> hogepodge: thanks
17:55:09 <oomichi> then one slot remains
17:55:16 <mtreinish> oomichi: really? so there are approved specs with a plan on how to evolve the cli
17:55:17 <sdague> hogepodge: I would put it in a real session, I think that unless you do so it doesn't really get advertised
17:55:26 <mtreinish> sdague: ++
17:55:42 <hogepodge> advertisement is good, and there is a push for much more active test development
17:56:21 <mtreinish> oomichi: I think masayukig must have been talking about migrating the old cli utils to the new cliff framework, but despite >1 yr we still don't think we have a concrete plan on the cli
17:56:31 <oomichi> mtreinish: can you put the link the spec?
17:56:36 <sdague> yeh, having a real CLI would be great
17:56:52 <hogepodge> within the defcore committee, so a full session would work great. I just don't want to step on any toes, or be presumptuous
17:56:55 <sdague> that would be something I think should get time, though it does need a driver
17:57:16 <sdague> hogepodge: I think a full session defcore / tempest is totally reasonable
17:57:19 <mtreinish> oomichi: there aren't any specs, that's what I was saying. I think there are real things to talk about
17:57:27 <mtreinish> probably a workroom topic
17:57:44 <sdague> though, that seems more like a fishbowl room instead of a workroom
17:57:55 <oomichi> mtreinish: ok, I see. who is a good person to run it?
17:58:19 <mtreinish> sdague: the tempest cli?
17:58:33 <mtreinish> oomichi: well masayukig had signed up for that in mitaka right?
17:58:42 <sdague> mtreinish: no, the defcore one
17:58:55 <mtreinish> sdague: oh, eyah I agree that's a fishbowl
17:59:02 <sdague> I could imagine that would bring in a bunch of spectators that want to follow along
17:59:29 <oomichi> mtreinish: but he is concentrating on the exsting one: migration thing
17:59:52 <mtreinish> well if no one else will lead it I guess I can
17:59:54 <oomichi> then I am not sure he will do that for the future work.
17:59:59 <oomichi> mtreinish: thanks.
18:00:08 <oomichi> sorry, the time is comming
18:00:13 <mtreinish> I'm just not sure I can commit to doing the work :)
18:00:15 <oomichi> lets move to qa channel. sorry about
18:00:19 <oomichi> #endmeeting