17:00:06 #startmeeting qa 17:00:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:11 The meeting name has been set to 'qa' 17:00:17 hi, who's here today? 17:00:30 o/ 17:00:40 o/ 17:00:41 hi 17:00:49 sdague: fnaval: mtreinish: hi 17:01:07 hi! sorry for a long absence. was on vacation 17:01:19 hello - i haven't attended in a long time; getting a feel of the state of Openstack QA now 17:01:26 ylobankov: hi, no worry :-) 17:01:52 ok, lets start 17:02:05 #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_14th_2016_.281700_UTC.29 17:02:11 ^^^ today agenda 17:02:24 #topic Specs Reviews 17:02:33 #link https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z 17:02:53 there are several specs on the gerrit 17:03:01 and most ones are red. 17:03:21 we need to update them as comments if wanting to approve 17:03:45 mine is the first, but it needs more time 17:03:53 that sould be WIP 17:04:18 oomichi: which one is that? 17:04:18 someone have a spec if picking it up now? 17:04:29 mtreinish: swagger one: https://review.openstack.org/#/c/297473 17:04:39 I am done as WIP 17:04:40 o/ 17:04:45 hogepodge: hi 17:05:01 at requires more considering 17:05:07 s/at/that/ 17:05:20 o/ 17:05:30 luzC: hi 17:05:33 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 sdague: yeah, that can make confusions 17:06:43 sdague: we need a big picture how to implement/create whole swagger at the first step 17:06:49 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 and potentially damaging 17:07:08 o/ 17:07:33 sdague: yeah, I agree 17:08:28 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 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 sdague: yeah, that is long-time goal 17:09:55 sdague: nice to do more actual merit thing 17:10:01 sdague: that is just PoC 17:10:11 as my hobby :) 17:10:32 can we move to the next topic? 17:10:46 yes 17:10:50 if not having more items about qa-spec 17:11:03 ok, let's move on 17:11:14 #topic Tempest 17:11:44 #link https://review.openstack.org/#/q/project:openstack/tempest+status:open 17:11:47 o/ better late than never 17:12:04 there are a lot of patches on the review 17:12:24 and most patches seem to be reviewing 17:12:31 that seems a good progress 17:13:05 I don't have special patches for picking them up here 17:13:33 anyone have patches or idea for picking up here? 17:13:48 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 I'm thinking we want it to be self testing so it should be all in 1 patch 17:14:12 #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/virt-device-role-tagging 17:14:18 that's what made me think about the topic 17:14:41 mtreinish: yeah, IMO it is nice to merge them in a single patch for verifying the schema 17:14:48 with the gate test. 17:15:28 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 sdague: patch 305456 - tempest - Update get server response schema 17:15:56 the model of doing patching to our schemas makes it actually quite hard to see what the schema really is 17:16:30 it would be nicer if those were exploded out, especially assuming a future where old stuff is actually deleted eventually 17:17:12 sdague: do you want to write all schema data for each microversion? 17:17:33 yeh, I think so 17:17:41 sdague: that could be big and a little hard to know what difference between microversions 17:18:20 they will be big, but they will let you evaluate what a particular resource looks like fully 17:18:55 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 I can see your point. current way is not so readable to know what is expected schema from human POV 17:19:12 right, and the point of this code in tree is for humans to understand it 17:19:19 we should optimize for humans 17:19:42 and make a tool to generate schema diffs between versions if that's helpful to see 17:20:03 mtreinish: humm, yeah, nice sample 17:20:14 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 I see 17:20:40 seeing it for the first time, I agree 17:21:14 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 sdague: like this spec: https://review.openstack.org/173334 ? 17:22:04 sdague: is that to convert json-schema to yaml files on tempest? 17:22:10 or are you talking about something else? 17:22:31 mtreinish: not that 17:22:44 sdague: heh, it had all the buzzwords resources and yaml :) 17:23:02 I think this https://pythonhosted.org/setuptools/pkg_resources.html 17:23:20 basically that there would be yaml files that can be programatically accessed without config 17:23:28 because the python package manages them 17:23:34 oomichi: yeh, for json schema in files 17:23:43 keystone is doing it in yaml, because it allows comments 17:23:45 and it's very nice 17:24:24 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 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 which means very few people can understand the validation, which makes it error prone 17:25:35 sdague: yeah, nice to better way for many people 17:25:52 and the package idea is interesting for me 17:26:47 I d like to confirm one conclusion 17:27:05 is it fine to write all json-schema data for each microversion? 17:27:28 I agree with that for readability 17:27:44 or any objections here? 17:28:04 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 if not, I will talk about it with gmann who is most active for this schema work 17:28:40 ok, will talk about it with gmann 17:29:05 #action oomichi talks about separation of json-schema for each microversion with gmann 17:29:22 do we have more topic about tempest here? 17:29:23 oomichi: I agree with mtreinish 17:29:54 sdague: I see, thanks for pointing it up 17:30:09 ok, let's move on 17:30:21 #topic DevStack + Grenade 17:30:49 #link https://review.openstack.org/#/q/project:openstack-dev/devstack+status:open 17:31:15 there are many patches about devstack also 17:31:37 someone want to talk about devstack/grenade here? 17:32:22 I don't have anything for this week 17:32:40 mtreinish: thanks. ok, let's move on 17:32:45 we could always pester sc68cal about the neutron rewrite :) 17:32:57 the only notable bits are the swift multinode code 17:33:04 sdague: oh, that all landed? 17:33:08 not yet 17:33:27 https://review.openstack.org/#/c/304468/ is the devstack change needed 17:33:27 sdague: patch 304468 - openstack-dev/devstack - Add variable SWIFT_STORAGE_IPS 17:33:51 then there is a bunch of d-g changes as well 17:34:00 but it would be good to land that bit 17:34:19 * mtreinish looks 17:34:19 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 (the multinode, rolling upgrade testing for swift) 17:35:02 cschwede is the person to talk to (but it's nearly 8pm for him right now) 17:35:24 notmyname: yep, he's been pretty responsive, I just +2ed the devstack patch he respun this morning 17:35:30 great, thanks 17:36:11 notmyname: are all necessary patches proposed already for testing? 17:36:48 oomichi: I don't know. I've been traveling this week, and I'm just catching up today 17:37:22 notmyname: ah, ok. I will check it later 17:38:15 can we move to the next topic if not having more about devstack/grenade 17:38:16 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 oomichi: yeh, we can move on 17:39:11 sdague: Thanks for info 17:39:34 * oomichi needs more time later for understanding 17:39:42 #topic Austin Summit 17:40:08 #link https://etherpad.openstack.org/p/newton-qa-summit-topics 17:40:30 I am trying to push topics to available slots based on voting 17:40:52 and one slot remains now 17:41:05 at the last work room. 17:41:34 oomichi: I don't think everyone pays attention to the interested section. I know I really didn't :) 17:42:12 mtreinish: humm, what is meaning? 17:42:34 is it difficult to understand the contents from the titles? 17:42:43 I didn't bother saying which sessions I was interested in on the etherpad (except for the first day) 17:42:54 I don't think it's a reliable voting system 17:43:32 do we actually need the ceph session? I thought that was basically all solved 17:43:44 sdague: you asked for it 17:43:45 we're just waiting on clarkb to get the ceph package mirror working 17:43:47 I updated the etherpad with my nick for the sessions im interested in 17:43:53 mtreinish: when did I ask for it? 17:44:01 sdague: my suggestion at this point would be for someone else to finish cleaning up that patch 17:44:09 bceause I keep getting pulled away to extinguish fires 17:44:30 clarkb: what sort of access does such a person need to be able to test it reasonably? 17:44:34 sdague: like a month ago? when we were talking about bring the ceph devstack plugin into qa 17:44:54 sdague: you just need to be able to run reprepro 17:44:54 mtreinish: right, but I thought we basically built a plan and almost fully executed it already 17:45:10 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 clarkb: ok 17:45:48 sdague: I thought there were open questions, like do we bake the plugin back into tempest 17:46:00 do we use ceph everywhere instead of lvm, etc 17:46:02 mtreinish: you mean devstack? 17:46:05 and the change is mostly done, it has some small things that need fixing and maybe a rebase 17:46:23 yeah, sorry devstack 17:46:47 mtreinish: ok, that's fine if there are more topics. I just thought that we were mostly sorted. 17:47:03 personally, I think a plugin is a better model 17:47:21 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 yeh, I would put the more generic devstack one into the fishbowl over that one for sure 17:48:03 and I'm not sure that it's really needed. Maybe make it a touch point on the friday meetup 17:48:43 sdague: that works for me, although now our session gap is 2 workrooms :) 17:49:02 oh.. 17:49:42 oomichi: I updated the etherpad for you 17:49:46 ok, how about having code sprint type sessions instead? 17:49:51 mtreinish: thanks, I see 17:50:06 for work rooms 17:50:36 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 I wouldn't be able to concentrate on it (and I'll likely just go to a different session) 17:51:49 mtreinish: hum, yeah 17:52:36 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 but we cannot work actually in the summit, nice to have sessions for creating ptaches based on the discussion 17:53:02 oomichi: what happened to the tempest resource tracker topic? 17:53:03 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 mtreinish: yeah, a nice idea if we don't have more idea now 17:53:19 oomichi: also I feel like we should have a cli topic 17:53:34 oomichi: and hogepodge just volunteered to run a defcore tempest session 17:53:43 so there are 3 topics to fill 2 slots :) 17:53:54 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 oomichi: ok, then how about Tempest CLI and tempest x defcore 17:54:30 mtreinish: yeah, I asked CLIs thing with masayukig, and he also doesn't have more 17:54:42 hogepodge: yeah, nice idea. thanks 17:54:51 hogepodge: can you write it on the etherpad? 17:54:57 oomichi: thank you, I will 17:54:58 hogepodge: https://etherpad.openstack.org/p/newton-qa-summit-topics 17:55:01 hogepodge: thanks 17:55:09 then one slot remains 17:55:16 oomichi: really? so there are approved specs with a plan on how to evolve the cli 17:55:17 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 sdague: ++ 17:55:42 advertisement is good, and there is a push for much more active test development 17:56:21 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 mtreinish: can you put the link the spec? 17:56:36 yeh, having a real CLI would be great 17:56:52 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 that would be something I think should get time, though it does need a driver 17:57:16 hogepodge: I think a full session defcore / tempest is totally reasonable 17:57:19 oomichi: there aren't any specs, that's what I was saying. I think there are real things to talk about 17:57:27 probably a workroom topic 17:57:44 though, that seems more like a fishbowl room instead of a workroom 17:57:55 mtreinish: ok, I see. who is a good person to run it? 17:58:19 sdague: the tempest cli? 17:58:33 oomichi: well masayukig had signed up for that in mitaka right? 17:58:42 mtreinish: no, the defcore one 17:58:55 sdague: oh, eyah I agree that's a fishbowl 17:59:02 I could imagine that would bring in a bunch of spectators that want to follow along 17:59:29 mtreinish: but he is concentrating on the exsting one: migration thing 17:59:52 well if no one else will lead it I guess I can 17:59:54 then I am not sure he will do that for the future work. 17:59:59 mtreinish: thanks. 18:00:08 sorry, the time is comming 18:00:13 I'm just not sure I can commit to doing the work :) 18:00:15 lets move to qa channel. sorry about 18:00:19 #endmeeting