16:00:30 <eglute> #startmeeting interopwg
16:00:35 <openstack> Meeting started Wed Nov 15 16:00:30 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <openstack> The meeting name has been set to 'interopwg'
16:00:52 <markvoelker> o/
16:00:53 <eglute> #chair hogepodge markvoelker
16:00:55 <openstack> Current chairs: eglute hogepodge markvoelker
16:00:58 <mguiney> o/
16:01:15 <georgk> hi
16:01:22 <eglute> #topic agenda
16:01:25 <eglute> #link https://etherpad.openstack.org/p/InteropVertigo.20
16:01:52 <eglute> Hello Everyone! It has been a while since the last meeting!
16:01:54 <eglute> Please update agenda as needed
16:02:13 <hogepodge> o/
16:02:28 <eglute> #topic OpenStack Summit Sydney
16:02:44 <eglute> I was not able to go- could someone summarize interop sessions?
16:03:06 <eglute> hogepodge or markvoelker?
16:03:13 <markvoelker> #link https://etherpad.openstack.org/p/SYD-interop-working-group Sydney etherpad
16:03:22 <hogepodge> The interop session wasn't strongly attended, markvoelker gave a presentation about how the program works
16:04:32 <markvoelker> Additionally we talked a bit with georgk about NFV scoring and how things were going over in OPNFV
16:04:43 <hogepodge> After reviewing the existing products in the marketplace, there are only two OpenStack Powered Storage products, one that hasn't been updated and one that is in maintenance mode.
16:05:59 <hogepodge> I've been floating the idea of cancelling the OpenStack Powered Storage program, since there isn't a tremendous interest in it, or reassessing it as a new vertical program that doesn't have a strong dependency on Keystone.
16:06:41 <eglute> hogepodge interesting. it is still needed for openstack powered anyways, right?
16:07:23 <hogepodge> Yes, but it's a component for Powered Platform, much like Cinder and Neutron are
16:07:49 <markvoelker> We could propose removing it from OpenStack Powered Platform as well, but consensus (anecdotal) seemed to be that we thought it made sense to leave it there.
16:07:50 <eglute> i think moving it to a vertical sounds reasonable
16:08:09 <hogepodge> OpenStack Powered Platform and OpenStack Powered Compute would remain the same.
16:10:12 <eglute> the new marketplace is very confusing to navigate
16:10:18 <hogepodge> Unless the market changes, there will be zero OpenStack Powered Storage products in the Marketplace within a year.
16:11:01 <eglute> hogepodge can you link to the two that have powered storage?
16:11:29 <markvoelker> #link https://www.openstack.org/marketplace/distros/distribution/ibm/ibm-spectrum-scale-for-object-storage
16:11:35 <markvoelker> #link https://www.openstack.org/marketplace/distros/distribution/swiftstack-inc/swiftstack-object-storage-platform
16:12:31 <eglute> thanks markvoelker
16:12:41 <markvoelker> Just thinking through the mechanics a bit here: if we were to propose removing that mark, what would we need to do?
16:12:57 <markvoelker> I'd think a patch to the json file and a new one for a storage vertical?
16:13:08 <eglute> i think we would need to announce it as deprecated and get board's approval
16:13:14 <hogepodge> Yes, and approval by the board. We should give them notice if we want to pursue it
16:13:51 <eglute> if we move it vertical, would anything change besides a name?
16:14:36 <hogepodge> I don't know.
16:14:41 <hogepodge> New territory.
16:14:47 <markvoelker> eglute: Well, one topic of discussion was that we could potentially remove the Keystone requirements
16:14:58 <markvoelker> E.g. use Swift and no other part of OpenStack
16:15:09 <markvoelker> (which is not an uncommon usecase)
16:15:24 <eglute> do you think we would get more people certifying that way?
16:15:42 <eglute> also, as a vertical, would this open for "openstack storage with ceph"?
16:15:51 <eglute> or similar name?
16:16:18 <markvoelker> I doubt the Board would approve a trademark program based on code we don't own, so likely not.
16:17:09 <eglute> markvoelker i was thinking similar to NFV
16:17:27 <eglute> but i think this case is different
16:17:50 <eglute> and you are right, board would not approve anything with a trademark we dont own
16:19:11 * markvoelker_ 's wifi dropped
16:21:03 <eglute> Ok, so I think we want to give the board a heads up about the change, either vertical or removal
16:21:09 <eglute> i think vertical is more reasonable
16:22:20 <eglute> any other comments on this?
16:23:03 <markvoelker_> Are we generally agreed on the idea of pursuing this?  I think we are, just didn't want to assume. =)
16:23:41 <markvoelker_> I can take a look at the changes needed to the json files this week if so; I have a couple of other patches I'm working on anyway.
16:24:03 <markvoelker_> That might give us something concrete to propose when we notify the BoD./
16:24:22 <hogepodge> Yes.
16:24:49 <hogepodge> My timing for getting a lot of this ready by January for the next BoD meeting is going to be really strained, though.
16:25:15 <hogepodge> I have high priority work items to finish this month that aren't interop, then KubeCon, then taking a much needed vacation for the rest of January.
16:25:25 <hogepodge> Rest of December that is, returning in January.
16:25:56 <markvoelker_> Oh right...next week is a US holiday too.  Ok, so that gives us a little breathing room I suppose.
16:26:19 <eglute> i think we may not need a lot for this
16:26:27 <hogepodge> Which brings up my next point (kind of out of order on the agenda), do we absolutely need to make our major updates to the board in January, or can we defer them?
16:26:43 <eglute> hogepodge it is up to us. we can wait till next meeting.
16:26:59 <eglute> we do have something in our rules that have a rough timeline
16:27:03 <eglute> but we could change it
16:27:26 <eglute> i think there will be in person BOD meeting in February
16:27:29 <eglute> i think that works too
16:28:19 <eglute> it is probably better because it gives new board members to familiarize with the WG and also discuss it in person rather than over the phone
16:29:09 <eglute> I think it would be really good to send out an email to dev and interop MLs discussing the possible change and solicit feedback
16:29:11 <hogepodge> I don't want to throw everything off because of my personal schedule, I just know that I'll have almost no time to devote to getting ready for the January meeting with my current workload and plans. It should be a group decision though.
16:29:35 <eglute> hogepodge i think most of us will be either busy or on vacation in december
16:29:50 <eglute> i am off 3 for 3 weeks in december
16:30:25 <markvoelker_> I can go either way...I think I'm done traveling for the year, so in spite of some vacation time my availability should actually increase. =)
16:31:20 <eglute> markvoelker_ that sounds good :) I vote to move the next guideline approval to February
16:33:02 <eglute> any comments? if not, we can move forward
16:33:23 <markvoelker_> Sounds ok to me then.
16:33:32 <eglute> thanks markvoelker_
16:33:43 <markvoelker_> #agreed Move guideline approval to February
16:33:51 <eglute> anything else from Sydney?
16:34:24 <markvoelker_> #agreed begin investigating deprecation of OSPS mark (markvoelker to work on json patches)
16:34:59 <eglute> thanks markvoelker_
16:35:18 <eglute> if nothing else regarding Sydney, next topic
16:35:28 <eglute> #topic Meeting next week
16:35:51 <eglute> I propose no meeting next week
16:36:02 <eglute> since it is a day before US Thanksgiving
16:36:10 <hogepodge> second
16:36:26 <markvoelker_> ++, I'll be away from internet access anyway
16:36:30 <eglute> #agreed no meeting next week
16:36:52 <eglute> #topic Need to pick new cycle name, current was "Vertigo"
16:37:04 <eglute> we can keep vertigo or pick a new one
16:37:22 <eglute> i would like to come back to this one
16:37:51 <eglute> please enter your suggestions while we discuss the rest of the agenda
16:37:52 <eglute> #topic Vertical Program Update
16:38:07 <markvoelker_> Sure, how about we make a note for folks to throw suggestions into the etherpad and we'll vote after the Thanksgiving break?
16:38:07 <eglute> thank you georgk for submitting the patch #link https://review.openstack.org/#/c/519732/
16:38:18 <eglute> markvoelker_ sounds good!
16:38:50 <eglute> #action everyone please suggest new names in etherpad for interop wg cycle name. This should be something fun :D
16:39:27 <eglute> georgk are you around?
16:39:32 <georgk> yes, I am here
16:39:34 <georgk> sorry
16:39:51 <eglute> Excellent!
16:39:52 <eglute> thank you for submitting the patch
16:39:59 <eglute> there are some items that need discussing in your scoring
16:40:04 <georgk> please have a look, it is my first attempt at scoring
16:40:28 <georgk> there are still two questionmarks in teh scoring sheet: the proximity criterion
16:40:57 <eglute> can you discuss them
16:41:35 <markvoelker_> Since we've broadly grouped these as CRUD for the first pass, it does get a bit confusing. =)  Let me see if I can clarify:
16:41:50 <georgk> my question is basically how to interpret this criterion: I tend to score it with a 1 based on my understanding that this trunk port functionality is releated to the generic port functionality of Neutron
16:42:15 <georgk> so, scoring it with 1 because of this relationship
16:42:16 <markvoelker_> Many moons ago when we did the scoring we'd consider each part of CRUD individually: e.g. we'd have one line in the sheet for create, another for read, etc.
16:42:23 <georgk> please let me know if that interpretation makes sense
16:42:49 <markvoelker_> So those capabilities would all be considered "promiximate" to one another (because why have a create capability if you can't also read and delete the thing?).
16:43:02 <georgk> ah, ok
16:43:20 <markvoelker_> So in this case, I think it's fine to score those as 1 for proximate
16:43:28 <georgk> it is about relationships between operations, not the features
16:43:34 <georgk> got it
16:44:23 <georgk> ok, I agree and score them with 1 then
16:44:37 <markvoelker_> ++, any other comments on that?
16:44:42 <georgk> I am still doing a bit more research regarding the ¨widely deployed¨ criterion
16:45:03 <georgk> it is a bit tricky to find out who is supporting this in commercial products
16:45:50 <eglute> georgk use your best judgement, at least for now. we have community review for people to tell us that we scored something wrong
16:46:14 <georgk> eglute: ok, will do
16:47:30 <eglute> also i think it would be helpful if you started listing the tests that would go under each capability
16:47:53 <eglute> because if there are no tests, we cant include them
16:48:43 <georgk> yes, absolutely
16:48:53 <georgk> I checked the tests already and we shoudl be covered
16:49:21 <eglute> excellent!
16:49:27 <georgk> I can create an initial nfv guideline and list the tests there
16:49:50 <eglute> georgk yes that would be very helpful
16:49:54 <georgk> sure
16:50:31 <eglute> are there any other comments besides the need for everyone to review?
16:51:20 <eglute> #action everyone please review and comment patch #link https://review.openstack.org/#/c/519732/
16:51:52 <eglute> anything else on verticals?
16:52:02 <eglute> #topic Microversions
16:52:09 <eglute> hogepodge i assume no updates on this, correct?
16:52:27 <hogepodge> correct
16:52:43 <eglute> #topic Scoring 2018.02 guideline
16:52:55 <eglute> i think we are just missing neutron for this one
16:53:07 <eglute> markvoelker_ have you had a chance to look?
16:53:25 <markvoelker_> Not since Sydney. =)  But I can finish it up this week now that I'm back.
16:53:34 <eglute> excellent thank you markvoelker_
16:54:14 <eglute> mguiney luzC had a question regarding cinder
16:54:23 <eglute> "LuzC - question to mguiney: Is she refactoring cinder V2/V3 in next.json to reflect the tempest changes (See full comment on this patch set 1)? "
16:55:12 <eglute> i think i may have merged it too early
16:55:17 <eglute> #link https://review.openstack.org/#/c/509337/
16:56:19 <mguiney> yeah, was wondering about that
16:56:36 <eglute> mguiney can you please review and submit a new patch if needed?
16:56:42 <mguiney> I can refactor, of course
16:57:07 <mguiney> That completely slipped my mind, apologies
16:57:11 <eglute> that would be great, thank you mguiney
16:57:23 <eglute> mguiney no worries. we have skipped a lot of meetings lately
16:57:51 <eglute> almost out of time, but last question
16:57:52 <eglute> #topic Add ons
16:58:03 <eglute> do the add-on programs need the TC flag?
16:58:17 <eglute> i think we have that for the other official capabilities
16:59:09 <markvoelker_> You mean the tc-approved-release tag?  I'd say not.
16:59:12 <eglute> yes!
16:59:16 <eglute> thank you markvoelker_
16:59:30 <eglute> makes sense to me
16:59:52 <eglute> though i think add-on projects would like to see them,
16:59:53 <markvoelker_> (actually I guess it's tc:approved-release now since they changed it)
17:00:10 <eglute> out of time,
17:00:27 <eglute> thanks everyone
17:00:30 <eglute> #endmeeting