16:00:14 <hogepodge> #startmeeting interopwg
16:00:18 <openstack> Meeting started Wed Apr 12 16:00:14 2017 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:22 <openstack> The meeting name has been set to 'interopwg'
16:00:34 <hogepodge> #chair markvoelker
16:00:34 <openstack> Current chairs: hogepodge markvoelker
16:00:39 <markvoelker> o/
16:00:46 <catherineD> o/
16:01:02 <hogepodge> #link agenda https://etherpad.openstack.org/p/DefCoreRoble.19
16:01:25 <hogepodge> Hi everybody! eglute is out for the meeting today
16:01:55 <Rockyg> o/
16:02:56 <hogepodge> Please add any agenda items to the etherpad
16:03:03 <hogepodge> #topic 2017.08 Guideline
16:03:25 <hogepodge> (it's been so long since I've run a meeting let's see if I remember all of the commands)
16:03:55 <hogepodge> cinder and nova, both are on my plate, and I have yet to send either patch up.
16:04:13 <hogepodge> We've had a lot of good feedback from the nova team that I need to encode in the scoring patch.
16:06:28 <hogepodge> glance, mguiney sent a scoring patch up, with feedback from brian rosamita
16:06:32 <hogepodge> #link https://review.openstack.org/#/c/451167/
16:06:49 <hogepodge> mguiney: any comments?
16:07:14 <mguiney> i am viewing thw comments right now, hadnt seen them yet
16:08:38 <hogepodge> he made some comments about the scoring, and the availability of the image import capability
16:09:10 <hogepodge> think it's worth making another iteration on the scoring patch
16:09:28 <mguiney> awesome, i will get a patch going to relfect those changes
16:09:52 <mguiney> sorry for the feedback delay there
16:10:09 <hogepodge> mguiney: ah, he just let the comments this morning. it's no problem. :-D
16:10:50 <hogepodge> anything else on glance?
16:11:25 <luzC> o/
16:11:35 <hogepodge> with neutron we go to markvoelker
16:12:02 <markvoelker> An interesting thing has come up in discussion: LBaaS.
16:12:34 <markvoelker> A lot of tools now support LBaaSv2 and some providers (like, say, the Kubernetes provider) use it.
16:12:57 <markvoelker> However there are some bits that make this tricky...like the move toward Octavia
16:13:30 <markvoelker> (E.g. do you require the "classical" neutron bits as designated sections, or Octavia...which far fewer clouds currently ship)
16:14:00 <markvoelker> So I think maybe the appropriate thing to do here is just go ahead and propose some LBaaS capabilities just to kickstart a more formal discussion
16:14:14 <hogepodge> markvoelker: is octavia api compatible with classic neutron lbaas?
16:14:26 <markvoelker> Yes, octavia supports LBaaS v2
16:14:45 <hogepodge> lbaas is something we're seeing much more demand for, so it's definitely something we should be discussing
16:14:49 <luzC> yes my understanding is that Ocatavia is replacing LBaaSv2 - I guess LBaaSv2 will soon be deprecated
16:15:30 <hogepodge> I'm ok with having multiple providers for a capability, assuming they are test agnostic
16:15:45 <markvoelker> YEah, and I think that's going to be the biggest issue with LBaaS...Octavia's going to fall short on adoption for a little while longer, Neutron LBaaS may fall down on future direction
16:15:55 <Rockyg> my take, also.  the future of lbaas is octavia
16:16:05 <markvoelker> So designated sections are going to be awfully tricky
16:16:20 <markvoelker> But I think if we start the discussion on this now, we'll likely be in a better spot down the road
16:16:29 <hogepodge> markvoelker: can we just add an "or" statement?
16:16:50 <markvoelker> I think "or" is problematic
16:17:11 <hogepodge> in the future, as more projects fragment to better distribute work, this will continue to be a thing
16:17:14 <Rockyg> it's similar to thenova-net to neutron move
16:18:15 <markvoelker> Rockyg: sort of.  In that case the capabilities were actually a lot different too.  In this case the API's are identical.
16:18:28 <hogepodge> we kind of already have an or, in the sense that we allow multiple backends to different APIs. I don't know why allowing multiple APIs from the OpenStack ecosystem is problematic, aside from potential mechanics. Say hummingbird becomes a thing in the openstack ecosystem, I'd like for deployers to be able to make a choice.
16:18:47 <Rockyg> Well, that makes *this* a bit easier.
16:19:49 <Rockyg> So, if we have a test case that works for both versions, the or could be the designated code section
16:19:52 <markvoelker> My gut feeling is that it's probably too late in this cycle to have an "or" discussion, so my plan is as follows (let me know what you think):
16:20:03 <Rockyg> That's easier to do than different functionality
16:20:19 <Rockyg> different api def's....
16:20:20 <markvoelker> 1.)  I'm going to add a few LBaaS capabilities to the scoring sheet.  I think it's unlikely we'll end up adding them *this time*, but it'll help foster discussion
16:21:07 <markvoelker> 2.) I'd like to get some clarification from the BoD around the concept of differing implementations of the same API for cases like these.  We can point them to the gerrit discussion and ask for a take.
16:22:04 <markvoelker> 3.)  We can also discuss how to handle designated sections as part of the new schema goign forward
16:22:20 <Rockyg> ++
16:22:48 <luzC> ++
16:22:54 <markvoelker> (we don't really have a construct for that today...we could simply not require either implementation, but that also opens the door to things being used that aren't actually developed in the community and I think the BoD wouldn't be happy with that)
16:23:23 <hogepodge> Sounds like a good plan. As part of signaling and discussion, I think it's worthwhile to plan the next guideline with lbaas as advisory. I'd rather not wait a whole year before we can even consider requiring it.
16:24:57 <hogepodge> markvoelker: I'm not so sure about that analysis, we can say OpenStack Project X -or- OpenStack Project Y without admitting projects outside of our ecosystem. I understand the concern, though.
16:25:23 <markvoelker> hogepodge: we don't have a construct for either/or in the schema today though.
16:25:31 <markvoelker> Nor do we have precendent
16:25:55 <markvoelker> So basically I think we want to proceed carefully here
16:26:16 <hogepodge> It's just language in a designated section, though? We already include conditionals. Tests are the hard cases, as they should be to guarantee the API contract.
16:26:48 <markvoelker> We need to have a look at the tests too though--there are some differences there
16:27:55 <markvoelker> E.g. octavia actually has it's own set of tests in-tree via a plugin interface
16:27:55 <hogepodge> Still, signaling this as an issue to the board is important. And we would need tests that evaluated the capabilities appropriately. Also, as with the Keystone v2->v3 and Cinder v2->v3 there are a whole host of deprecation and transition issues
16:28:15 <markvoelker> (and they're primarily scenario tests)
16:28:24 <Rockyg> we either need to make the tests work for both, or the api's don't demonstrate the interop trait.
16:29:04 <smcginnis> Not really following, but just want to point out Cinder v2 is (should be?) exactly the same as Cinder v3.
16:29:11 <smcginnis> v3 just adds microversion support.
16:29:17 <Rockyg> We're getting to the real hard parts of this, now.
16:29:32 <markvoelker> Correct...and we're very late in the cycle. =)  Hence, my plan here is put something in the scoring docs to kickstart that whole discussion on the larger issue of multiple implementations
16:30:10 <markvoelker> I'm actually thinking of doing it as a separate patch from the other Neutron stuff because I thin it'll require a lot more dicussion
16:30:22 <hogepodge> smcginnis: yes, but there are issues regarding the endpoint, and new micro versions have landed on v3 which at some point in the near future may necessitate the dropping of v2. But I'm very grateful about cinder's commitment to interop between v2 and v3
16:32:12 <markvoelker> Ok, I think I've sucked up enough time with this today. =)  I'll push the discussion over to gerrit shortly.
16:32:35 <smcginnis> hogepodge: ;)
16:33:28 <hogepodge> ok, moving on
16:33:39 <hogepodge> The swift scoring patch is up
16:33:55 <hogepodge> #link https://review.openstack.org/#/c/453453/
16:35:37 <hogepodge> Seems pretty straight forward, but comments welcome naturally.
16:35:49 <hogepodge> Please review.
16:36:10 <hogepodge> luzC: is up on Keystone
16:36:40 <luzC> I'm pushing the patch in a bit...
16:37:14 <luzC> I reviewed one new capability but requires admin credentials
16:37:32 <luzC> should I still score it?
16:37:51 <hogepodge> which capability?
16:38:07 <hogepodge> can it operate without admin?
16:38:07 <markvoelker> Hmm...does it require admin credentials because the test happens to be built that way, or because that's a default policy setting?
16:38:13 <luzC> identity-v3-validate-token
16:38:17 <Rockyg> put it on the scoring sheet, but it will not pass because of admin
16:38:36 <Rockyg> But having it documented on the scoring sheet is important
16:39:39 <hogepodge> It requires admin access based on the API docs
16:39:56 <hogepodge> #link https://developer.openstack.org/api-ref/identity/v3/?expanded=validate-and-show-information-for-token-detail
16:39:57 <luzC> hogepodge: yes
16:40:41 <luzC> I'll document it on the scoring sheet
16:40:50 <hogepodge> I can go either way on putting it there as a reference or just leaving it off.
16:41:43 <luzC> ok,
16:41:43 <markvoelker> I'd lean toward just including a note along the lines of "X was considered but is an admin-only capability".  We've done similar for some Neutron stuff IIRC
16:42:16 <markvoelker> refer to https://github.com/openstack/defcore/blob/master/working_materials/scoring.txt#L66-L71
16:42:24 <hogepodge> +1
16:42:36 <catherineD> +1
16:42:46 <markvoelker> Or more concisely: https://github.com/openstack/defcore/blob/master/working_materials/scoring.txt#L119-L120
16:42:50 <mguiney> +1
16:43:38 <hogepodge> Sounds like a good plan. luzC: anything else on Keystone?
16:43:53 <luzC> yes
16:44:17 <luzC> for existing required capability identity-v3-tokens-create
16:44:25 <luzC> noticed there is only one test case
16:45:07 <luzC> should I add a TODO for add 2  more test cases
16:45:09 <luzC> ?
16:45:30 <hogepodge> If there are aspects of the API that can be tested, more coverage is always welcome
16:45:52 <markvoelker> A single test case is ok, but if there are more tests available that are usable it's fine to consider adding more.
16:46:36 <luzC> but that TODO goes where? into the scoring? tempest bug?
16:46:57 <hogepodge> luzC: storyboard
16:46:58 <Rockyg> Should be a tempest bug.
16:47:05 <catherineD> should go to Interop-wg bug list
16:47:06 <Rockyg> In storyboard....
16:47:20 <luzC> ok, get it I'll add it
16:47:23 <markvoelker> If tests exists, you can file a bug with us.  If they don't and you think there is insufficient coverage of a feature, log a bug with the relevant project/tempest.
16:47:54 <Rockyg> what markvoelker said
16:48:40 <hogepodge> thanks luzC
16:49:14 <hogepodge> We have about 10 minutes left, and a few pending topics to get to. Are we good to move on?
16:49:32 <markvoelker> ++
16:49:42 <hogepodge> #topic Name Change
16:50:06 <hogepodge> #link https://review.openstack.org/#/c/433414/
16:50:16 <hogepodge> this patch stalled out, any update on the progress?
16:50:41 <markvoelker> So the patch still hasn't seen any action from infra.  I totally forgot to ping them due to some business travel this week.
16:51:15 <hogepodge> Let's ping fungi :-D
16:51:18 <markvoelker> I'm back now, so I'll make a point of clearing that off my plate this afternoon
16:51:25 <hogepodge> great, thanks
16:51:44 <hogepodge> Anything else we want to add on that? Are there other outstanding items?
16:52:23 * markvoelker has nothing further
16:52:26 <hogepodge> #topic Schema v2
16:52:41 <hogepodge> #link https://etherpad.openstack.org/p/InteropSchema2
16:52:50 <hogepodge> #link https://review.openstack.org/#/c/430556/
16:54:09 <hogepodge> I'm assuming that while we're focused on scoring we don't have too much for this?
16:54:22 <markvoelker> pretty much...=/
16:55:48 <hogepodge> ok, moving on then
16:55:57 <hogepodge> #topic Bostin Summit Sessions
16:56:33 <Rockyg> OK.  I've got a how we score talk with Luzc and I think luzC said she wasn't going to be there
16:56:42 <hogepodge> I had a forum session accepted for the add on programs. http://forumtopics.openstack.org/cfp/details/22
16:57:05 <hogepodge> luzC: :-(
16:57:22 <Rockyg> So, volunteer for a second?
16:57:36 <Rockyg> unless we can get luzC  there....
16:57:54 <hogepodge> I'll propose mguiney if she's willing to fill in, or I can fill in too.
16:58:05 <Rockyg> unless we can get luzC  there....
16:58:12 <Rockyg> ++ on mguiney
16:58:20 <Rockyg> That would work, too.
16:58:25 <mguiney> I would be very interested!
16:58:30 <markvoelker> RockyG I'm on that session too, so I can help
16:58:37 <Rockyg> oh, cool.
16:58:40 <Rockyg> Thanks.
16:59:04 <Rockyg> I knew I wasn't alone.  mguiney might have a cool tool to demo, too.
16:59:15 <hogepodge> lots of good talk links in the etherpad
16:59:34 <hogepodge> #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18637/openstack-interoperability-challenge-and-interoperability-workgroup-updates-the-adventure-continues
16:59:34 <luzC> yes, I'm not attending the summit, willing to help with the presentation... in favor of mguiney taking my place
16:59:41 <mguiney> hopefully! I plan on getting started on that in the second half of this week, if all goes well
16:59:43 <hogepodge> #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18575/interop-working-group
16:59:51 <hogepodge> #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/17743/defcore-to-interop-and-back-again-openstack-programs-and-certifications-explained
16:59:59 <hogepodge> #link  https://www.openstack.org/summit/boston-2017/summit-schedule/events/18529/how-an-interop-capability-becomes-part-of-the-openstack-interop-guidelines
17:00:06 <Rockyg> excellent.  gotta run to another meeting...I'll check back later....
17:00:07 <openstack> dansmith: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
17:00:09 <hogepodge> With that we're out of time. Let's take this to interopwg
17:00:12 <hogepodge> #endmeeting