16:00:33 #startmeeting interopwg 16:00:36 Meeting started Wed Jul 12 16:00:33 2017 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:39 The meeting name has been set to 'interopwg' 16:00:46 o/ 16:00:54 Hello Everyone! 16:01:07 Here is today's agenda, please update as needed: #link https://etherpad.openstack.org/p/InteropVertigo.7 16:01:29 hogepodge is traveling so won't be able to attend today 16:01:38 anyone else here for the interopwg meeting? 16:01:54 #chair markvoelker 16:01:54 Current chairs: eglute markvoelker 16:02:13 I'm actually half available 16:02:16 markvoelker may or may not be able to join us 16:02:21 oh thats great! 16:02:24 #chair hogepodge 16:02:24 Hi everybody 16:02:25 Current chairs: eglute hogepodge markvoelker 16:02:45 o/ 16:03:04 * markvoelker runs in all out of breath from another meeting and plops down in a chair 16:03:06 * eglute waves to everyone 16:03:18 o/ 16:03:37 I hope everyone had a nice day/week off last week 16:03:50 I was out and today is my first day back 16:03:57 so i have a bit of catching up to do 16:03:59 eglute: welcomeback 16:04:12 * eglute failed at sunscreen and is now a zebra 16:04:16 thanks kgarloff 16:04:41 once again, here is agenda: https://etherpad.openstack.org/p/InteropVertigo.7 16:05:06 #topic Denver PTG 16:05:17 I am not sure who added question about PTG, 16:05:22 but yes, we are going to be there 16:05:39 and we absolutely can meet with the glare team 16:05:47 Monday Tuesday and board meeting on Sunday 16:05:50 is glare team same team as glance 16:06:06 I did. 16:06:08 Correct, and we are sharing room with refstack again 16:06:20 Rockyg yes we are going to be there 16:06:25 No, glare came out of glance v3 efforts 16:06:51 Afaik 16:07:03 ok so do we need to meet with glance team as well as glare team? 16:07:03 the TC was discussing the thread about Glare talkinh about replacing glance 16:07:45 no. I thin it will be a what and how discuusion. all theoretical 16:07:59 thanks Rockyg, i will review TC meeting logs 16:08:06 #link https://etherpad.openstack.org/p/InteropDenver2017PTG 16:08:20 I'll see if I can find the thread link, too. 16:08:21 etherpad for agenda items for Denver 16:08:25 thanks Rockyg 16:09:36 Please start updating the etherpad with topics 16:09:45 also let us know if you are planning on attending 16:10:09 anything else regarding PTG? 16:10:34 #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/119442.html 16:10:53 Use the conference block please if possible 16:11:03 thanks Rockyg 16:11:04 * eglute is booking today! 16:11:18 * kgarloff cannot do that much international travel :-( so no PTG for me 16:11:22 Just a note: BoD/TC/UC meeting Sunday Sept. 10 at the PTG 16:11:38 (for those interested) 16:11:53 thanks markvoelker 16:11:59 i will be there 16:12:16 I likely will be as well (but haven't actually booked a flight yet) 16:12:16 kgarloff if there are any topics you are interested in being addressed, let us know 16:12:30 markvoelker glad to hear that 16:12:32 eglute: thanks -- will do 16:12:54 #topic Patch reviews 16:13:08 eglute: Overall direction ... of InterOp WG is really good, so nothing fundamental to be addressed 16:13:16 Fix some pep8 warning: #link ix some pep8 warning https://review.openstack.org/#/c/478662/ 16:13:19 thanks kgarloff 16:13:42 Everyone, please take a quick look at the outstanding patches 16:13:47 * markvoelker thought he already +2'd this but must have dreamt it 16:14:04 * eglute blames gremlins in the interwebs 16:14:14 i think we had multiple pep8 patches 16:14:26 thanks markvoelker 16:14:29 * markvoelker blames 2am meetings 16:14:35 Add aliases for test_update_volume_metadata_item 16:14:35 https://review.openstack.org/#/c/479673/ 16:15:03 that one looks straighforward to me 16:15:04 * hogepodge blames his bad pep8 skills 16:15:51 o/ 16:15:56 hello luzC! 16:16:15 thanks luzC for reviewing alias patches 16:16:20 maybe hogepodge could use some peptobismol! 16:16:22 Everyone, please the same 16:16:42 * eglute is waiting to dial up to 11, pep11 16:17:09 Add aliases for test_update_snapshot_metadata_item #link https://review.openstack.org/#/c/479683/ 16:17:17 and the drmmer explodes 16:17:18 another alias patch 16:17:42 they look good to me, but would appreciate another set of eyes 16:17:59 Add Aliases For VolumeV2 Test Cases Part 2 #link https://review.openstack.org/#/c/478619/ 16:18:03 more aliases. 16:18:20 please review and comment on the patches! 16:19:23 kgarloff: you said they were tests that were removed? 16:19:50 Those should be aliased or flagged 16:19:55 * markvoelker makes a mental note to make sure these all get into 2017.08 either in https://review.openstack.org/#/c/472848/ or as subsequent patches 16:20:34 s/they/there 16:20:44 hogepodge: Right, let me look up the details 16:21:08 markvoelker i added on the etherpad as well 16:21:48 hogepodge: So what you say is that tempest-latest should work with Guideline-2017.01 against Mitaka -- if not, we should add an alias or flag some test (or submit a fix to tempest)? 16:22:29 If tests were removed we should have been warned. So they probably moved 16:22:55 So if moved use an alias. If removed use a flag 16:23:23 You can search for them by using the idempotent ID 16:23:58 anything else regarding outstanding patches + aliases? 16:24:58 #topic 2017.08 Guideline 16:25:03 * kgarloff is searching for the mail with details 16:25:12 #link https://review.openstack.org/#/c/472848/ 16:26:07 mguiney any updates on https://review.openstack.org/#/c/467528/ 16:26:43 yes! 16:27:31 i've made the modifications mtreinish suggested, and touched base with the creator of the conflicting patch 16:28:15 the standing plan is to let the version of the catalog client present in my patch stand 16:28:24 so at this point is this the only thing preventing us from merging 2017.08? 16:28:38 thanks mguiney that sounds good 16:28:42 i believe so (sorry) 16:29:02 eglute: that actually doesn't stopping us from landing the 2017.08 patch. It's marked advisory, not approved 16:29:09 will be pushing a patch after i give it one more once over to make sure i didn't miss anything 16:29:14 mguiney, hey, it's stiil July.... 16:29:16 So we can continue to ammed the 2017.08 file after that merges 16:29:32 markvoelker true! should we merge it then? 16:30:10 everybody, if you havent reviewed https://review.openstack.org/#/c/472848/ yet please do so 16:30:18 I would like to. That way we if more alias/flag requests come in we can add them to all the right guideline docs at once rather than having to update sparate patches 16:30:35 ok... lets merge today then 16:30:41 otherwise we will miss things 16:31:12 any objections? 16:31:24 markvoelker are you merging aliases into your patch? before merging it? 16:32:54 luzC I think there are a few outstanding. But again, we can add those in subsequent patches. 16:33:02 ok 16:33:52 any other comments? 16:34:02 +1 on the patch if you are ok with it being merged 16:34:36 #topic Schema 2.0 16:35:02 #link https://review.openstack.org/#/c/430556/ 16:35:49 thanks everyone for reviewing it 16:35:55 any discussions on the schema? 16:36:21 hogepodge has done a great job on it i think 16:36:35 +1 16:36:53 would also like it to be merged if there are no more discussion on it 16:36:55 +1 16:37:01 I'd like to get it in a good place so I can produce advisory extension programs for next guideline 16:37:12 +1 16:37:17 This means soon 16:37:18 How do folks feel about the qeustions asked in teh commit message? 16:37:22 hogepodge: +1 16:37:57 markvoelker: The Open questions section 16:38:06 yep 16:38:16 markvoelker link? 16:38:24 oh 16:38:25 sorry 16:38:27 https://review.openstack.org/#/c/430556/12//COMMIT_MSG 16:38:41 thanks markvoelker i am too slow 16:38:48 Yeah, it's wip but I'll address concerns and get a final patch up 16:38:48 My answers: no, no, don't know, don't know, yes 16:39:17 "make required_since optional?"-- any good reason for doing so? 16:39:31 i did have a question re: the target approval date 16:39:38 eglute: It's useful historic information, so keep it 16:40:38 would there be any real benefit to changing those to a more generic date format, or is it just a matter of readability/style 16:40:45 yeah, I think tht's a good point. eliminates the need to look at multiple guidelines 16:40:45 kgarloff i agree, but i wonder if hogepodge had a particular reason for it 16:40:48 It doesn't make sense for things that have never been required 16:41:17 hogepodge you mean things like advisory? 16:41:22 Or for non board programs 16:41:51 are there any of those in progress or interest in non-board programs? 16:42:23 This is supposed to be applicable past our process 16:42:26 mguiney: I'm lost ... more generic than %Y-%m-%d ? 16:42:49 i think it was in yyyy.mm, correct? 16:42:55 Yes, we want projects to produce their own Interop guidelines regardless of if they will become official 16:42:59 ah. true, hogepodge 16:43:07 hogepodge i would say no then, i rather not over-engineer for hypothetical situations 16:43:39 (for date of approval, i mean) 16:43:55 mguiney: on previous schema it was in the form "\\d{4}-\\d{2}-\\d{2}" example "2017-01-24" now it will be something like "2017.01" 16:43:56 The date format was meant to match up the style we use. Is exact date important? I can go either way 16:44:43 i like yyyy.mm 16:44:59 %Y.%m is not necessarily an obvious date format ... 16:45:27 kgarloff but it matches our guideline naming 16:45:38 makes sense. i had just been wondering if there is an immediate benefit to changing it 16:45:52 eglute: fair comment, but then the field is spurious, no? ;-) 16:46:26 kgarloff i think it depends on the perspective. 16:46:31 i am ok either way! 16:46:57 redundant would have been a better word -- but I think this detail is not really all that importnat 16:47:02 i was mostly just wondering the context, thank you for addressing this 16:47:24 my vote would be to not change it if there's no good reason to, but I'll leave it to folks more experienced ... 16:48:22 ok, so lets go back and address each question from the top: 16:48:28 "make required_since optional?" 16:48:41 +1 or -1 16:48:50 -1 16:48:58 -1 16:49:06 -1 16:49:06 I'm on cell phone and have some weird constraints, so my typing skills are very limited 16:49:16 hogepodge no problem 16:49:17 -1 16:49:38 ok, "make required_since optional?" answer: no 16:49:49 "make idempotent_id optional?" yes or no 16:49:54 +1 -1 16:49:54 -1 16:50:04 -1 16:50:12 -1 16:50:24 -1 16:50:32 "make idempotent_id optional?" answer: no 16:50:38 "change date of approval to match more generic dates?" 16:51:02 +1 / -1 16:51:04 +1 16:51:13 -1 (no strong opinion though) 16:51:17 +1 16:51:30 -1 (for make idempotent_id optional) 16:51:32 -1 but not strong 16:51:35 (generic = yyyy.mm?) 16:51:43 mguiney correct 16:51:45 -1 16:51:49 If someone can leave a review summarizing the results of the vote that would be awesome 16:51:49 +1 16:51:59 hogepodge will do after we cover all 16:52:12 catherineD why -1 on date change? 16:52:22 would this affect refstack? 16:52:39 do not need change that is not absilutely necessay 16:52:55 catherineD ok, that is a good reason for me 16:52:56 That's true. 16:53:00 markvoelker what do you think? 16:53:05 from developer perspective 16:53:15 true... 16:53:21 And, if there is ever a need to *not* have it, we can add a qulifier 16:53:35 like -1 or something 16:53:44 +0, I"m not sure it's an important enough detail to argue much about. =) 16:54:03 markvoelker cool! then we will say no to the date change 16:54:12 "change date of approval to match more generic dates?" answer: no 16:54:19 "components structured correctly? redundancy with designated sections?" 16:54:23 any discussion on this? 16:54:39 i think it looked ok to me when i looked 16:54:56 can you elaborate on the question... 16:55:32 i think hogepodge is referring to the structure of the schema, but i could be wrong 16:55:57 Just wanted to make sure I don't 16:56:14 Didn't miss anything or do anything weird 16:56:34 I kinda feel like we might be able to get away with collapsing components to simplify, but that's really just an optimization we could do in 2.1 later if it proves useful. Not worth bogging this down further IMHO. 16:56:45 i think once you start working on the new programs if we need to amend the schema we can. 16:57:00 Ok 16:57:03 also all changes go until we get approved by the board, and after just bump the number 16:57:20 "splitting platforms and extensions up into different fields for better granularity?" 16:57:34 this question is also more complex and required detailed review 16:57:51 Last question, two next schemas or one? 16:58:03 Should next be 2.0? 16:58:06 so if everyone please review the new schema with those questions in mind, that would help 16:58:15 hogepodge what do you mean 16:58:19 Next guidelines I mean 16:58:21 Ditto here: I think what's here is sufficient and we can optimize later if necessary 16:58:28 next.json should be in 2.0? 16:58:33 Yes 16:58:39 For the board approval 16:58:43 how about 2017.08? 16:58:55 IMHO leave 2018.08 in 1.x format since it's already what the community has been reviewing. 16:59:00 It's approved, so no 16:59:03 cool 16:59:05 RefStack can not render 2.0 yet 16:59:15 We can move to 2.0 later when refstack is ready and we have programs that can use it. 16:59:17 Excellent point 16:59:21 so 2017.08 in 1.x format 16:59:23 so, lots of reasons to keep it 16:59:31 so if next.json with 2.0 is merge then RefStack will break with next 16:59:49 thanks everyone. we didnt get to cover vertical programs topic, so will move that to next week 17:00:01 we are out of time, i will be around in the interop irc 17:00:07 thank you, bye 17:00:07 thank you!! 17:00:11 #endmeeting