16:01:03 #startmeeting interopwg 16:01:04 Meeting started Wed May 31 16:01:03 2017 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:08 The meeting name has been set to 'interopwg' 16:01:09 o/ 16:01:14 #chair markvoelker 16:01:15 Current chairs: eglute markvoelker 16:01:22 hello everyone! 16:01:26 #topic agenda 16:01:39 #link https://etherpad.openstack.org/p/InteropVertigo.2 16:01:45 please update agenda as needed 16:02:07 o/ 16:02:13 raise your hand if you are here for interop meeting :) 16:02:15 o/ 16:02:37 o/ 16:02:49 #topic 2017.08 Guideline 16:03:10 thanks everyone that helped with scoring, all scoring patches were merged 16:03:55 i think what is left is creating the actual 2017.08.json 16:04:19 we can do that after the latest flagging/removing tests patches get merged 16:04:41 any other comments on 2017.08? 16:05:30 #topic Add aliases for test_volumes_list 16:05:39 mguiney: has some patches up for keystone that may impact the guideline 16:05:45 oh that one is abandoned now, nevermind then. 16:06:00 actually testing for capabilities that we would want to have as advisory 16:06:05 thanks hogepodge and mguiney 16:06:53 ok! i saw mguiney added them to the agenda, thank you 16:07:04 (sorry for the late addition) 16:07:31 np, thank you! 16:08:00 o/ 16:08:16 actually lets move them up on the agenda, since they relate to 2017.08 16:08:35 #topic non-admin token validation test 16:08:43 #link https://review.openstack.org/#/c/467493/ 16:09:16 so if these tests get merged, does that mean we will be adding new capabilities to 2017.08? 16:09:50 I think that is the goal, yes 16:10:31 because both of these capabilities are testable without admin capabilities 16:10:44 i think technically it would be a tad late for our timeline, but i think i am ok with that. What do others think? 16:11:12 It's something we've talked about and worked on, so I'd be fine with it 16:11:31 It's not like we're adding capabilities that didn't exist in OpenStack beforehand, they just weren't tested in a way we could use 16:11:45 i agree hogepodge 16:12:03 Yeah, I think I'm ok with this. For reference, this was discussed in https://review.openstack.org/#/c/456774/ back in April I beleive 16:12:19 They are also widely used and critically important capabilities. 16:12:26 markvoelker correct 16:12:55 mguiney would you create a new patch for keystone once these tests get merged? 16:13:34 seems like i merged the keystone patch too soon 16:13:53 for the keystone scoring? yes, I will absolutely be able to do that 16:14:08 great, thank you mguiney 16:14:31 #action mguiney create new keystone scoring patch with added tests once the new tests get merged 16:15:23 #topic catalog standardization test 16:15:32 #link https://review.openstack.org/#/c/467493/ 16:16:25 mguiney would this test be also added if it merges? 16:16:36 added to the new guideline that is 16:16:45 that would be the other keystone patch! theres a bit more work i still need to do on that one, but if anyone has feedback i'd love to hear it 16:16:54 *keystone test patch 16:16:59 thank you mguiney! 16:17:17 Hmm, same link? 16:17:43 heh, markvoelker is right. mguiney? 16:17:53 Those links both go to the non-admin token test. I think the second one we wanted to discuss was the catalog standardization stuff. 16:18:10 oh dear 16:18:12 hold on 16:18:16 https://review.openstack.org/#/c/467528/ 16:18:29 is the catalog standardization test 16:18:31 that's the one 16:20:06 mguiney in your comments you state that "This test may belong as an "admin" capability" 16:20:31 do you know yet whether it will require admin? 16:20:52 that would be because the catalog inly exposes part of the catalogs if the user only has the access to see some of the services 16:22:05 ok, so if the test is admin, then we would not be adding to keystone capabilities 16:22:16 yeah, that would make sense 16:22:28 Two tests might be appropriate then, one that checks admin-only services and one that checks non-admin services 16:22:50 Because it's still something we want to check for. Not having nova or keystone publicly available would be a problem, for example. 16:23:03 that would make sense 16:23:19 ++, the services we're including in guidelines should be available to non-admin users. 16:23:32 agree... if we have one non-admin test, that can be added 16:24:12 so if the test is added in time, would that also add new capability? i need to look :) 16:24:22 the one i have up, when smoothed out a little, should work as the nonadmin test 16:24:44 eglute: yes, this would be a new capability (so advisory at best) 16:25:29 ok, so do we need a deadline until when advisory capabilities can be added to 2017.08? 16:25:40 eglute: markvoelker: should the capability be existing for more than 2 releases? 16:26:05 catherine_d|1 yes... is this new? 16:26:19 catherine_d|1: Yes, the capability being tested needs to apply to all releases covered in the guideline. 16:26:27 It's tricky. Catalogs have existed from the beginning, but the enforcement is new. 16:26:31 catherine_d|1, good point. but another reason for advisory. Let folks know it's coming as tehy upgrade 16:26:42 The enforcement tries to catch common variants 16:26:49 TEchnically there's nothing the test uses that hasn't been in Keystone forever 16:27:01 So I'd think it's a good idea to make it advisory sooner rather than later 16:27:34 Weeeellll...actually that's not quite true since it's using v3 of the API, which hasn't been there forever. But you get the point. =) 16:27:42 works for me! 16:27:47 usually capabilities in the advisory section will be candidated for required in the next JSON ... 16:27:49 lets add it as advisory if we can 16:28:56 anything else on this topic? 16:28:57 does that meet the 2 releases requirement? Just want to see how this stack up against our own policy for consistency 16:29:29 catherine_d|1: The API's being used here have been available for many, many releases now. So there's nothing new on that front. 16:29:38 What's new is that we're enforcing particular values in the catalog 16:29:51 So it will not fall afoul of the 2-release requirement 16:30:14 It's more a matter of how fast we can get feedback as to whether this would trip anyone up. 16:30:17 that is good then 16:30:33 policy vs capability 16:30:48 ++ 16:31:08 This should be communicated on the interop and dev mailing lists 16:31:16 Let's not surprise anybody. 16:31:21 and ops? 16:31:29 yes, ops too. thanks Rockyg 16:31:49 I would even be willing to put a note in the goodline to the effect of "this is one we'll wait on for two full cycles before we switch to required since it arrived late", but I'd like to start getting the feedback soon. 16:32:01 * s/goodline/guideline/ 16:32:19 we can't communicate until 2017.08.json is created 16:32:32 so we need a deadline for adding things to next.json 16:33:10 I think the user commitee ml, also, with all the vertical affinities in the subject -- lcoo, ldt, etc 16:33:13 btw, if we decides to put heat and designate on "addon" 16:33:26 do we need the tests to be added as well ? 16:33:43 zhipeng_ yes, add-ons would also have tests 16:33:59 zhipeng_, yes, we do. we should at least get them in as advisory. 16:34:14 so that would mean the same deadline , right ? 16:34:27 markvoelker hogepodge what deadline do you have in mind for changes to next.json 16:34:39 zhipeng_: Not necessarily. What we're creating here is the OpenStack Powered guideline, not add-on guidelines. 16:34:41 is 2 weeks enough? 16:35:01 This should be considered as a side project to the Powered guideline. 16:35:11 so add-ons would be another guideline based upon schema 2.0 ? 16:35:12 Let's not tie them tightly together. 16:35:22 zhipeng_: basically, yes. 16:35:23 ok got it :) 16:35:35 but still it needs to be ran before the board ? 16:35:48 zhipeng_ correct, everything is board approved 16:35:53 eglute: June 8 is when testing is supposed to start, which is approximately one week from now...is that enough time? 16:36:07 That seems like the safest way forward. I can try to get a major update done soon. I have minor surgery tomorrow, but should be able to give it full attention on Monday and Tuesday. 16:36:14 mguiney do you think 1 week is enough for all the changes? 16:36:47 as i mentioned, the catalog test is not as close to ready as the other one, but i can certainly try and getthat ironed out 16:37:25 mguiney ok, if it is not ready in 1 week (or almost ready) it may have to be pushed out to the next guideline 16:37:50 * mguiney nods 16:37:53 that makes sense 16:38:07 thank you mguiney for your work!! 16:38:16 anything else on this? 16:39:20 thanks everyone! 16:39:41 #action eveyrone review patches https://review.openstack.org/#/c/467493/ and https://review.openstack.org/#/c/467528/ 16:39:55 #topic Create tools to increase ease of scoring 16:40:01 #link https://review.openstack.org/#/c/458716/ 16:40:17 thanks to luzC for reviewing! 16:40:34 if luzC and others are good with the latest changes, we can merge this patch later this week 16:41:27 any other comments on the tool? 16:42:10 Just a nit that it would be nice to add some inline help like we have in the other scripts 16:42:19 We can do that in a follow-up if you like though. 16:42:30 thanks markvoelker for reviewing it 16:42:42 ahhhh yes that would be a good idea 16:42:54 i can do that and push the patch asap 16:43:09 thanks mguiney! 16:43:12 anything else? 16:43:54 #topic Add Aliases For VolumeV2 Test Cases Part 1 16:44:08 #link https://review.openstack.org/#/c/462860/ 16:44:17 lucZ helped review the patch 16:44:28 zhipeng_ are you able to fix it? 16:44:39 and I will update it before the end of the week, see if multiple aliases pass the CI 16:44:43 yes I think so 16:44:53 it is just so many lines lol 16:44:57 zhipeng_ thanks! and thanks to luzC for reviewing it! 16:45:10 zhipeng_ if it helps, break it up in several patches 16:45:26 yep I already break it to two :) 16:45:39 thank you zhipeng_! 16:46:05 and thank you for working on this! 16:46:06 anything else on this patch? 16:46:26 #topic Remove test_delete_active_server 16:46:31 #link https://review.openstack.org/#/c/463944/ 16:47:12 markvoelker reviewed it this morning, so we will give time for updates 16:47:39 I'll just note here that the related patch in tempest is still undergoing some discussion as well 16:48:09 #link https://review.openstack.org/#/c/463942/ 16:48:16 I think gist of it is that the same functionality in the test that's being proposed for removal is covered elsewhere...but in a less atomic way. 16:49:06 I haven't had a chance to look at the other tests that cover this functionality yet though (E_TOO_MUCH_BIZ_TRAVEL) 16:49:57 It would be great if folks can take a look though--removing this test from tempest isn't necessarily a foregone conclusion yet, and it might actually work out better for us if it stays. 16:50:05 thanks markvoelker... there is always so much to do. 16:50:19 +1 16:51:40 Losing interop test coverage is never good. 16:51:48 Rockyg agreed 16:51:56 #topic Remove duplicated testcase test_get_private_image 16:52:01 #link https://review.openstack.org/#/c/454489/ 16:52:05 more test removal 16:52:14 but only in an old guideline 16:52:27 so not sure that it is relevant still, i think not 16:53:01 Yeah, I'd prefer we not start going back and updating guidelines that really can't be used anymore...just makes more work for no particular end, IMHO. 16:53:09 should we be archiving old guidelines? 16:53:18 I'm convinced by Mark's argument. 16:53:24 We already mark them as superseded 16:53:24 me too! 16:53:41 By archive you mean stick them in a separate directory or something? 16:54:05 markvoelker yes 16:54:34 as for this patch, i think we need to abandon it 16:54:38 catherine and the refstack team are ok with updated to account for that, I'd be ok with it. 16:54:52 (if) 16:55:00 I think I proposed that a year or two ago and we decided against it....I'd have to find that patch to remember the context though. 16:55:16 hogepodge is right... refstack might still pull the old guidelines 16:55:27 markvoelker may have been refstack related? 16:55:37 could be 16:55:42 we'll give you a week, markvoelker to find that patch ;-) 16:56:15 ok, we can save this discussion for later, since only 4 min left 16:56:22 But, refstack could pull from the archive for old stuff 16:56:46 good separation 16:56:54 good hygiene 16:56:58 #topic Flagging Regarding Public Cloud Subnet 16:57:03 Rockyg: already done...the discussion was in this patch: https://review.openstack.org/#/c/202345/ 16:57:23 #link https://review.openstack.org/#/c/460372/ 16:57:27 (see Rob's comments on patchset 7) 16:57:32 >P markv 16:58:58 thanks markvoelker for digging that up... i have forgotten all about it 16:59:05 regarding flagging subnets 16:59:09 any comments? 16:59:17 everyone, please review 16:59:59 also, please review https://review.openstack.org/#/c/463263/ 17:00:11 and we are out of time 17:00:25 thanks everyone, if needed, i will be in the interop irc later today 17:00:28 #endmeeting