16:01:27 #startmeeting interopwg 16:01:28 Meeting started Wed Jan 25 16:01:27 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:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:32 The meeting name has been set to 'interopwg' 16:01:39 o/ 16:01:39 #topic agenda 16:01:44 Hello Everyone! 16:01:53 here is our agenda for today: #link https://etherpad.openstack.org/p/DefCoreRoble.10 16:02:00 please add/update as needed 16:02:15 o/ 16:02:35 o/ (half here half in the kolla meeting) 16:03:04 Mark said he will be traveling today, so looks like he might not be able to make it 16:03:51 anyone else here for the interop meeting? 16:04:26 do you think we have quorum for the meeting? 16:04:29 hi everyone 16:04:32 Congratulations to everyone on another successful guideline release. 16:04:46 hogepodge: +1 16:04:54 yes, thanks everyone for all your help! 16:05:06 #chair hogepodge 16:05:07 Current chairs: eglute hogepodge 16:05:14 #topic 2017.01 guideline 16:05:37 the board approved the guideline, and this is the report we presented to the board: https://docs.google.com/document/d/1MFotmauuwZXmmhiTj_iyzUIOcTZA1V8JXgPk8Lqdc-4/edit?usp=sharing 16:05:53 thanks catherine_d|1 for catching the issues with the guideline 16:05:59 before it was approved :) 16:06:12 +1 catherine_d|1 16:06:27 #topic PTG 16:06:33 just a reminder to please add things to the agenda 16:06:35 eglute: yw ... thanks everyone for merging the guideline in time .. that was very quick 16:06:58 #link https://etherpad.openstack.org/p/RefStackInteropWGAtlantaPTG 16:07:13 since there wont be a board meeting at PTG, i will not be staying the whole week 16:07:51 * eglute needs to book travel 16:08:27 #topic Flagging two network-l2-CRUD capabilities 16:08:28 #link https://review.openstack.org/#/c/422715/ 16:09:08 Zhipeng Huang is asking to flag a capability 16:10:27 reason: [D405] The test reflects an implementation choice that is not widely deployed even if the Capability is widely deployed 16:10:28 what does everyone think? 16:12:00 for networks-l2-CRUD, there are a few things going on 16:12:17 eglute: and anyone else who is running a public cloud, are those things you would expect to have? 16:12:46 I do not know what we do in public cloud, but i can find out 16:13:08 I'm with Zhipeng here (but that's no surprise) 16:13:17 test_create_port_with_no_securitygroups seems like a reasonable test to flag. 16:13:28 I can't say either way without more data, but I also don't find the request entirely objectionable. 16:13:32 CT Cloud Platform https://www.openstack.org/marketplace/public-clouds/china-telecom/ct-cloud-platform passed 2016.08 ...this is a public cloud 16:14:06 i think most ports created would have some security groups associated with it 16:14:27 not sure if there is a test that test creation of port without looking at security groups 16:14:47 however, at the minimum flagging thiese 2 tests seem to not relaxing security ... so it may make sense 16:15:03 i agree with catherine_d|1 16:15:11 there is a test above those two: test_create_port_in_allowed_allocation_pools 16:15:16 so they do create ports 16:16:27 catherine_d|1 garloff and everyone else if you could comment on the PR that would help 16:16:36 My proposal would be to clean up the patch a bit (it needs to be applied to 2016.08 also, and have the reason modified, plus a longer commit message) and leave in the queue for a week for comments. 16:16:38 eglute: will do 16:16:46 thank you catherine_d|1 16:16:54 hogepodge: +1 16:16:55 eglute: Will do, thanks 16:16:59 I don't have any strong objections to it, but I want to make sure it airs for just a bit. 16:17:14 hogepodge would you post that comment on the PR? 16:17:55 if i understand what is being tested correctly just looking at the test names, i think they are reasonable to flag. 16:17:59 but i agree with hogepodge 16:18:30 anything else on this patch? 16:18:54 #chair markvoelker 16:18:55 Current chairs: eglute hogepodge markvoelker 16:19:14 * markvoelker_ sneaks in the back after being slightly delayed at the airport 16:19:28 #chair markvoelker_ 16:19:29 Current chairs: eglute hogepodge markvoelker markvoelker_ 16:19:43 #topic Glance change: Implement and Enable Community Images 16:19:50 #link https://review.openstack.org/#/c/369110/ 16:20:27 I think this was brought up on the mailing list 16:20:45 do we have any glance experts that would be able to tell if this will affect our guidelines? 16:21:27 My initial read from a quick skim was "probably not" but I've not had a chance to look at it closely yet. 16:21:28 visibility: community is something that would be useful for us as public cloud provider 16:22:04 This is from skimming through the blueprint (quite some time ago) -- will need to look closer to make sure the definition is clear enough 16:22:44 my main concern if it will affect existing guidelines and cause current tests to fail-- or changes to existing tests. 16:23:04 i guess we can take that as an action item to review 16:23:14 if there are no takers, i can take a look 16:23:24 eglute: I can volunteer to look at this a bit closer, but not until at least next week. I'm going to be doing some stuff related to that section of code soonish anyway. 16:23:32 eglute: the more the merrier though. =) 16:23:41 markvoelker_ that would be great! 16:23:42 thank you! 16:23:50 If the tests fail because of this change, then the tests are broken 16:23:55 One problem we need to solve is how to hide old images without making them inaccessible ... 16:24:14 branchless tempest is supposed to be branchless with the promise of stability over supported releases 16:24:27 #action markvoelker_ will review https://review.openstack.org/#/c/369110/ 16:24:50 hogepodge then hopefully the tests are working :) 16:25:08 hogepodge: sure, it'd be nice to find out if the tests are broken before people trying to get a license agreement do though. 16:25:23 markvoelker_: agree :-D 16:25:36 garloff- hopefully this patch helps you do so 16:25:50 anything else on glance? 16:26:27 #topic Schema v2.0 16:26:28 hogepodge any updates? 16:26:47 We presented the rationale to the board yesterday. 16:26:59 I commit to having a first pass by our meeting in two weeks 16:27:13 (I'll be at our staff offsite next week, so won't be at this meeting) 16:27:30 that would be great, thanks hogepodge 16:27:59 #topic name change 16:28:26 Were we planning on changing the repo name? 16:28:27 thanks everyone who worked on the rename, we got most things renamed 16:28:37 that was going to be my next question 16:28:41 repo and launchpad 16:29:04 i am ok with leaving it as is, what do others prefer? 16:29:42 eglute: I thought we had decided otherwise *if it is no big trouble doing so technically* -- I have no strong opinion on this myself 16:30:13 Yes, I think the plan was to change it 16:30:30 markvoelker_ had taken the action but it was supposed to be one of the last things 16:30:55 happy to revisit but that was the original plan anyway 16:30:56 Right, the idea was to get the docs all updated and 2017.01 landed before we switch the repo name 16:31:02 i think shamail and garloff are right, they have better memory than me 16:31:09 Both of which are now done, btw. =) 16:31:14 markvoelker_: +1 16:31:28 so when do we want to have the change happen? 16:31:51 I think the sooner the better at this point...would be nice to do it while the patch volume is low. 16:32:02 markvoelker_ agree 16:32:10 We will likely see a lot more patches around the PTG, so makes sense to do it soonish. 16:32:16 markvoelker_ +1 and before the PTG/midcycle 16:32:26 +1 16:32:43 +1 16:32:51 markvoelker_ are you still ok with making the change? 16:32:56 eglute: Sure 16:33:02 thanks markvoelker_ 16:33:09 just let us know when you are able to do so 16:33:18 I can start the wheel turning next week if that works for folks...in the interim it would be best to try to clear out the patch queue as much as possible 16:33:25 Awesome 16:33:32 +1 16:33:39 thanks markvoelker_ 16:33:47 Please add me to the change markvoelker_ and I will be glad to review it. 16:33:58 Will do 16:34:03 right now we have only one patch 16:34:26 how about launchpad? i know we have not been using it lately 16:34:32 #link https://bugs.launchpad.net/defcore 16:35:21 eglute: I see a lot of email about using story board ... 16:35:43 are most projects switching to storyboard? 16:35:57 I'm ok with sticking with LP for now, but I do think we should change the project name (or is that a matter of just creating a new one? I forget...) 16:35:59 I am not sure 16:36:21 creating a new one is probably the most frictionless way 16:36:22 I think opinions on StoryBoard vary...a lot of projects got scared off when it nearly died off a while back 16:36:26 we can clean out the old one 16:36:43 hogepodge i think cleaning out would be good 16:36:53 I've been encouraged to encourage others to move to storyboard 16:36:53 markvoelker_: that is true ... RefStack started with StoryBoard 16:36:53 hogepodge: Seems like it would be relatively simple to create the new one, mark all the bugs as also-affects the new project, then remove the old one? 16:37:10 we can wait on storyboard then, and maybe discuss it during PTG 16:37:18 But there's not that much there to lose, so whatever is easiest. =) 16:37:18 but it seems like there is new momentum this round .. 16:37:50 catherine_d|1 i added storyboard to the PTG agenda 16:38:27 anything else on the rename? 16:38:40 #topic New components/add-on programs 16:38:51 this ties to the schama 2.0 16:39:04 we talked about New components/add-on programs during our last midcycle, 16:39:12 but have not moved forward with it 16:39:53 hogepodge will have a draft schema in a couple weeks, so hopefully we can get some work done on it before ptg 16:40:21 #action hogepodge to write first draft of 2.0 schema 16:40:26 if you have any thoughts now on what New components/add-on programs should look like, please share :) 16:41:06 Let's use this for drafting out ideas https://etherpad.openstack.org/p/InteropSchema2 16:41:21 We've discussed orchestration and dbaas before. There has also been talk about vertical-specific programs (NFV for example). 16:41:55 So basically we'll want a schema flexible enough to take a couple of different types of programs into account I think. 16:42:15 There's definitely interest from some NFV folks to take advantage of our guideline infrastructure 16:42:43 i would be very interested in figuring out what openstack/nfv would look like 16:42:57 Should this accommodate things beyond what you (can|should) do with tempest? 16:43:22 garloff: we technically already have a structure for things outside of Tempest 16:43:46 garloff good question. unfortunately, TC said that everything that is in Interop Guideline must be tested with things in tempest. 16:44:16 markvoelker_, eglute: that does not match in my mind ... 16:44:46 TC is also pushing everyone breaking out their tempest plugins into separate repos, which helps us with multiple sources 16:44:50 markvoelker_: actually, that's why you said "technically"? 16:44:51 but yes, technically our guidelines could support tests that are not in tempest 16:45:16 ok 16:45:30 garloff: we had planned on using external testing for swift, then the TC passed a resolution saying "no, we want you to use tempest for interop guidelines" 16:45:31 garloff: right. The TC resolution is here: https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html 16:45:59 However given the new motion to break stuff out of Tempest...that may be worth revisiting. 16:46:11 (that movement really got started after the TC resolution) 16:46:26 markvoelker_ when did this motion begin? after Barcelona? 16:46:37 A little before, IIRC 16:46:56 in Barcelona I talked to Doug, and he thought that projects can bring back to tempest proper the tests that are part of interop 16:47:29 yes, we're supposed to evaluate all project tests, then pull them into tempest if we want them to be interop 16:47:49 hogepodge that seems like a lot of overhead for projects 16:47:54 hogepodge: I guess the discussion on heat showed that at some point, testing API semantics may not be sufficient or at least not hte best abstraction for what you want to test 16:48:17 maybe we are not at that point yet, hard to tell ... 16:48:44 Which adds layers of overhead, especially in context of flagging and so on. It seems silly to me, and we're not bound by TC resolutions as we're a board group. But, it's nice to play nice. 16:49:21 garloff technically we could support other tests. but it gets back to that TC resolution 16:49:22 garloff: for some things, I could see us doing scenario tests 16:49:35 especially for additional programs like NFV 16:49:48 we could have a meeting with projects that are going the plugin route + TC representative and see if we can work things out 16:49:57 and have them revoke their resolution 16:50:48 i would like to play nice with everyone, but it seems to me that this resolution might be a bit too restrictive 16:51:02 is this something we should discuss at PTG? 16:51:36 eglute: Maybe, but I think it would be good to understand the sort of programs we may want to develop first. 16:51:49 That way we can have a more informed discussion with the TC 16:51:54 markvoelker_ good point 16:52:05 So, perhaps an item for later in the agenda 16:52:43 ok i will add it as tentative 16:53:11 anything else? 16:53:28 #topic open floor 16:53:48 anything else we should discuss? 16:54:03 You probably already covered this while I was delayed (sorry for being late!) but: thanks everyone who contributed to 2017.01 and the renaming work! 16:54:27 yes, thanks everyone! 16:54:28 we will start the next one soon :D 16:55:17 Also, a quick note on the new Board: 16:55:38 Here's something I was wondering: Currently DefCore Compute + DefCore Object = DefCore Platform 16:56:10 Do we need finer granularity in the future so we define InterOp for projects not as widely deployed as well? 16:56:22 * garloff still using old name, sorry 16:56:37 ChangBo Guo from EasyStack (starting a new term on teh Board) contacted me after the Board meeting last night to say he's interested in participating in the InteropWG. Please do help us welcome him and other newcomers and get them up to speed. 16:57:17 thanks markvoelker_ for that! hopefully they will be joining our meetings in the future. 16:57:19 garloff: That's something that's been brought up...generally speaking, we'd like to get to a point where community projects can define interop guidelines for themselves 16:57:30 These may not be required for logo/trademark agreements 16:57:39 garloff- schema 2.0 should help with that 16:57:56 But would help users of those lesser-used projects navigate products 16:58:23 And would hopefully provide an on-ramp for those projects that may become part of logo programs in the future 16:58:27 garloff: https://docs.google.com/document/d/1MFotmauuwZXmmhiTj_iyzUIOcTZA1V8JXgPk8Lqdc-4/edit#heading=h.19sxczb6yn0f 16:58:56 And with that we're about out of time and I need to head to my boarding gate.... 16:59:07 safe travels markvoelker_ 16:59:10 thanks everyone! 16:59:21 #endmeeting