16:00:46 <eglute> #startmeeting interopwg
16:00:46 <openstack> Meeting started Wed Oct 11 16:00:46 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:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:49 <openstack> The meeting name has been set to 'interopwg'
16:00:51 <markvoelker> o/
16:00:57 <georgk> hi
16:00:59 <eglute> #chair markvoelker hogepodge
16:01:02 <hogepodge> o/
16:01:02 <openstack> Current chairs: eglute hogepodge markvoelker
16:01:05 <eglute> #topic agenda
16:01:18 <Rockyg> o/
16:01:19 <eglute> Hello Everyone! Today's agenda: #link https://etherpad.openstack.org/p/InteropVertigo.18
16:01:28 <eglute> please feel free to update as needed
16:02:12 <eglute> hogepodge has a conflict, so his availability will be limited
16:02:30 <mguiney> o/
16:02:43 <markvoelker> #topic OpenStack Summit Sydney
16:03:09 <markvoelker> Just a general reminder here about the Forum session.  If folks would like to note other related sessions in the pad for general awareness, please do!
16:03:38 <markvoelker> Out of curiosity: who's going?  I know hogepodge and I are and eglute isn't.  Anyone else?
16:03:57 <georgk> I´ll be there
16:04:01 <markvoelker> \o/
16:04:07 <georgk> :-)
16:04:19 <dims> o/
16:04:37 <markvoelker> \o/ (again)
16:04:46 <Rockyg> I'm thinking I won't be making it.
16:05:34 <markvoelker> bummer
16:05:50 <Rockyg> which means someone will need to help georgk with the refstack/opnfv sessions
16:06:11 <markvoelker> hogepodge: ^^ (even though you're not here, just recording for the minutes)
16:06:13 <Rockyg> if they make it on the schedule.  which they should
16:06:46 <georgk> yeah...
16:07:11 <markvoelker> Anything else we need to talk about for Sydney today?
16:07:38 <markvoelker> #topic Verticals: NFV
16:07:52 <Rockyg> uh, on the etherpad at the top, should the "next" be sydney summit not boston summit?
16:08:12 <markvoelker> Rockyg: yes =p  Old copy/paste
16:08:26 <eglute> Rockyg thanks! will fix that :D
16:08:32 <markvoelker> Two topics I'd like to get some input on today for the NFV program:
16:08:57 <markvoelker> First, one of the questions that's come up while I've been drafting an initial capabilities list is how many releases we should cover
16:09:43 <Rockyg> great question
16:10:02 <markvoelker> As a reminder, the OpenStack Powered program covers 3.5 releases (e.g. you can currently get a logo agreement if you have a compliant offering that uses Mitaka, Newton, Ocata, or Pike)
16:10:18 <georgk> so, you are wondering if NFV is developing so fast that we cannot maintain a 3 release compatibiulity
16:11:05 <markvoelker> georgk: Partly, yes.  Some of the features we've been considering actually didn't appear until after Mitaka, for example.
16:11:50 <markvoelker> This could be a one-off issue (there have been a *lot* of NFV-driven changes in the past few releases, that may cool down a bit in terms of what's widely deployed enough to meet criteria though).  Or not.
16:12:19 <markvoelker> My general inclination is to stick with the precedent set by Powered for the time being and solicit some feedback
16:12:33 <markvoelker> I can make note of capabilities that don't make the list because of the timing in the scoring sheet
16:12:33 <eglute> maybe keep it in advisory until cover enough releases?
16:12:36 <eglute> would that work?
16:13:51 <markvoelker> eglute: That's an option too, but there's been some sentiment that there's been enough new stuff going into OpenStack in recent releases that's driven by NFV that we may end up with a pretty weak Guideline, at least initially.  E.g. realistically you may need more capabilities than what we require.
16:13:52 <georgk> eglute: that sounds reasonable
16:14:34 <eglute> markvoelker mitaka would roll off next year anyways, correct?
16:14:46 <eglute> if all the nfv features available in newton?
16:14:58 <eglute> or are they even later?
16:15:06 <eglute> we need to start out with advisory anyways
16:15:51 <markvoelker> As always, I think that depends a little on who you ask. =)  Hence I thought I'd bring it up here to discuss.
16:16:19 <eglute> markvoelker what do you propose
16:17:15 <markvoelker> eglute: Per above, my initial though is to stick with the coverage from Powered and I'll make note in the scoring worksheet of anything that doesn't get considered because of it that folks have asked about.
16:17:31 <markvoelker> That should give us a more concrete list and we can make changes as necessary.
16:17:34 <eglute> markvoelker sounds good
16:18:04 <markvoelker> Any objections?
16:18:11 <eglute> not from me!
16:18:51 <markvoelker> #agreed We'll stick with the 3.5 release requirement for the NFV vertical
16:18:58 <markvoelker> Ok, on to the second issue....
16:19:18 <markvoelker> One of the buckets of capabilities we're considering here is LBaaS.
16:19:20 <Rockyg> Yeah.  Remember the first powered guideline was awful weak, too.
16:19:34 <Rockyg> The third one finally got a little meat.
16:19:49 <markvoelker> As most of you are aware, there are currently basically two implementations fo the LBaaS v2 API: classic neutron LBaaS and Octavia.
16:19:52 <georgk> Rockyg: honestly, OPNFV has the same issue
16:20:45 <Rockyg> Yeah. It's hard to have stricter Openstack guidelines than OPNFV has for itself ;-)
16:20:50 <markvoelker> In my (completely anecdotal, YMMV) experience there are currently more deployments of classic neutron LBaaS in production, but the future direction is toward Octavia.
16:20:59 <eglute> Rockyg good point. We did follow up 1st guideline with 2 others pretty fast.
16:21:10 <markvoelker> We've talked about this once or twice now but haven't come down on a firm decision about how to handle it.
16:21:17 <eglute> markvoelker we had this issue with neutron vs nova networks
16:21:35 <Rockyg> eglute, ++
16:21:38 <eglute> not sure if it is the same exact situation
16:21:38 <markvoelker> eglute: this is different because they are two implementations of the same  API
16:21:46 <Rockyg> and glance v2
16:22:01 <markvoelker> Whereas nova-net vs neutron were very different capability sets and completely different API's
16:22:33 <eglute> markvoelker if apis are the same, are the tests the same?
16:23:13 <markvoelker> eglute: they *could* be in some cases.  Generally they aren't as of now.
16:23:27 <markvoelker> So, two things to think about with this situation:
16:24:03 <markvoelker> 1.) Do we think this is a general situation that's likely to come up more and more often (two implementations of the same API), or is this sort of a one-off?
16:24:57 <markvoelker> 2.)  If we want to consider saying "either implementation of the API is acceptable since a tool calling the API won't know the difference" then do we want to tackle this with a schema change, or try to just use comments?
16:25:02 <georgk> I am wondering about this: what about all the different Neutron backend implementations?
16:25:05 <markvoelker> The answer to 2 may depend on 1 obviously
16:25:34 <georgk> like different SDN controllers. Why are those not problematic? they also implement the same API
16:26:02 <markvoelker> georgk: the backend plugin/driver is generally abstracted: e.g. if I want to create a network or a port, the API call is the same whether my backend is OVS, NSX, or Linux Bridge.
16:26:20 <markvoelker> Plugins are explicitly not designated sections
16:26:25 <markvoelker> Whereas API code is
16:26:25 <Rockyg> Yeah.  In the early days, we talked about same api, different implementations.  that was the motivation for required code segments
16:26:28 <markvoelker> (generally)
16:26:32 <georgk> markvoelker: and there IS a difference in the LBaas v2 API
16:27:02 <georgk> ok
16:27:10 <Rockyg> but for other things, lke sdn controllers, especially stuff openstack doesn't control, we should ust have a good set of api tests and scenario test
16:27:18 <markvoelker> Well, again: the LBaaSv2 API generally provides an abstraction layer from whatever LB you're actually using (haproxy or NSX or whatever).
16:27:50 <markvoelker> But in this case if we want the API server to be a designated section, we'd have to make the neutron API designated, the Octavia API designate, or both.
16:28:15 <georgk> markvoelker: got it, thanks
16:28:28 <markvoelker> (and our schema is currently designed around a single implementation...e.g. there's no concept of "you can use A or B to meet this requirement")
16:29:06 <eglute> i would be inclined to say either implementation is fine for as long as API is the same but not sure about the tests...
16:29:37 <markvoelker> eglute: right, that's sort of the next point here...ok, I'll jump to that. =)
16:30:01 <markvoelker> So if the API implementations are the same, it's entirely possible that tests could be written agnostic of the implementation
16:30:15 <eglute> that would be ideal for us i think
16:30:39 <Rockyg> That would certainly demonstrate interop between the two implementations ;-)
16:30:40 <markvoelker> In practice, this mostly isn't the case (https://github.com/openstack/octavia/tree/master/octavia/tests/tempest and https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/tests/tempest for example)
16:31:06 <eglute> of course it is not...
16:31:46 <markvoelker> So, if we go with "either implementation is ok" then we also need to think about how to handle "you can pass test A or test B"...potentially.  Or we could just hold off making these required until we're sure we have agnostic tests.
16:31:50 <Rockyg> question is, could the lbaas test run successfully against Octavia and/or vice versa?
16:32:11 <markvoelker> Or we could wait until everybody runs Octavia and classical lbaas is removed from the treee...
16:32:15 <markvoelker> Or...
16:32:18 <markvoelker> Well, you get the picture.
16:32:23 <georgk> can we review the tests and only include those which are implementation agnostic?
16:32:57 <eglute> Rockyg would you be able to help us test it?
16:34:28 <markvoelker> georgk: Possibly.  Octavia does run some neutron tests at the gate.
16:34:48 <Rockyg> I can reach out to some of our guys and see what we can do.  Zhipeng and our Netron guys might be able to do some stuff.
16:35:00 <eglute> Rockyg that would be great
16:36:12 <markvoelker> We can look into that as part of building the capabilities list, but what I'd like to get down to today is: do we want to potentially allow two implementations of an API, and is that something we want to build into the schema?
16:36:47 <markvoelker> I'll point out that the later means we might need to make some adjustments to RefStack (particularly if we end up with "test A or test B").
16:36:52 <eglute> markvoelker i think that is not the ideal scenario but one we should consider. especially if it is just different tests for same api
16:38:29 <Rockyg> Yeah.  I would think ther should be a set of common tests for a specific network function
16:39:08 <Rockyg> non common tests would be to help the user understand which implementation is the right one for them
16:39:20 <markvoelker> Ok, so what I'm generally hearing is "let's see how far we can get with an 'or' for designated sections but not different tests".  Yes?
16:39:27 <eglute> Yes
16:39:29 <Rockyg> yes.
16:39:43 <Rockyg> georgk, what do you think?
16:40:20 <markvoelker> Ok, I'll start drafting with that assumption then and we'll see how it turns out (/me makes mental note to set up both implementations in his lab this week for testing).
16:40:36 <eglute> thank you markvoelker for tackling this
16:41:02 <georgk> yes
16:41:36 <markvoelker> If this works out, I'm hopeful we may not need a schema change.  I'm pretty sure I can handle the designated sections stuff in commentary and RefStack doesn't really do much with designated sections anyway (other than display them as part ofthe guideline)
16:41:56 <eglute> thanks markvoelker
16:41:56 <markvoelker> Ok, let's move on...19 minutes to go and plenty of agenda stuff left
16:42:09 <markvoelker> #topic Microversions
16:42:28 <markvoelker> This may be a short topic since I think hogepodge had the AI's from last week but isn't around. =)
16:42:49 <eglute> hogepodge said he had no updates on his items
16:42:56 <eglute> unless mguiney can add anything?
16:43:08 <hogepodge> Just have to send a patch. Find time to send the patch
16:43:16 <eglute> thank you hogepodge
16:43:21 <markvoelker> nifty
16:43:36 <markvoelker> Ok, moving on....
16:43:47 <markvoelker> #topic Scoring for 2018.01
16:44:13 <markvoelker> Patches are drifting in and discussions are being had, which is good.  =)
16:44:25 <markvoelker> Are there specific items folks want to discuss here today?
16:44:42 <eglute> i think nova one needs discussion
16:45:04 <eglute> but perhaps first let people review?
16:45:24 <markvoelker> eglute: You mean the patch adding keypairs?
16:45:28 <eglute> yes
16:45:37 <markvoelker> #link https://review.openstack.org/#/c/509955 Nova scoring patch
16:46:15 <eglute> though i dont think Matt is on IRC right now
16:46:28 <markvoelker> Was there something you wanted to bring up about it in particular?  Looked pretty reasonable to me...
16:46:43 <eglute> so this would include microversion
16:46:48 <eglute> looks reasonable to me as well
16:47:01 <eglute> but wanted to make sure people review and voice any concerns
16:47:34 <eglute> if no concerns, reviews and +1 :)
16:48:13 <markvoelker> IMHO this is something that's been around since Kilo and I've yet to run across a cloud that didn't support it that I can think of.  If hogepodge does end up adding a microversion annotation to the schema we can add that later.
16:48:34 <Rockyg> ++
16:49:06 <eglute> great! will get +2 from me as well
16:49:12 <markvoelker> Ok, if folks can land their comments/approvals in gerrit por favor, that's be lovely.
16:49:19 <eglute> +2
16:49:23 <markvoelker> Other scoring items folks want to talk about today?
16:49:49 <eglute> luzC noted her patch needed discussing
16:50:10 <eglute> #link https://review.openstack.org/#/c/509638/
16:50:36 <eglute> though I don't think luzC is online right now
16:50:49 <eglute> Question: identity-v3-list-projects capability was marked required 2017.09.
16:50:49 <eglute> But the only TC available was flagged since it needs 2 users.
16:50:55 <eglute> Should we move the capability back to advisory until TC is fixed?
16:50:55 <eglute> or until other suitable TCs are added?
16:51:04 <eglute> i am not sure i am entirely clear on the question
16:51:20 <eglute> we could wait to discuss it till luzC is online
16:51:39 <eglute> oh, TC i think is Test Case
16:51:44 <eglute> not technical committee
16:52:03 <markvoelker> I'm ok with leaving it (and leaving the flag) personally.  I'd like to check if there's been any motion on a better test though.
16:52:42 <eglute> i agree.. maybe luzC could check on a better test
16:52:51 <markvoelker> Reverting a capability to advisory is something I don't think we've actually ever done.
16:53:13 <markvoelker> Ok, other scoring stuff for today?
16:53:18 <eglute> we could break new ground and try it :D but yes, flagging is fine
16:53:20 <markvoelker> (7 minutes...)
16:53:39 <eglute> not from me!
16:53:41 <markvoelker> #topic Add-on Programs
16:53:47 <markvoelker> hogepodge: anything to note here today?
16:54:35 <hogepodge> no, same, no room for interop work this week sadly
16:54:56 <markvoelker> Thanks.  Ok then, moving along
16:55:03 <markvoelker> #topic Future project consultation
16:55:21 <markvoelker> Any updates here (none from me this week...)?
16:55:22 <mriedem> blarg keypairs
16:55:49 <mriedem> Rockyg: told me to show up
16:55:52 <mriedem> but now it seems i don't need to
16:56:25 <eglute> mriedem thank you for the patch!
16:56:26 <markvoelker> mriedem: I think we're good.
16:56:54 <markvoelker> #topic Open Floor
16:57:02 <Rockyg> sorry, matt!  but you did a good enough job we all agreed
16:57:08 <eglute> +1
16:57:17 <markvoelker> OK gang, that's pretty much today's agenda.  Anything folks want do discuss in the remaining 3 minutes?
16:57:23 <eglute> markvoelker no other updates from me, thank you!!
16:57:46 <Rockyg> wait, got lance on keystone...
16:58:12 <lbragstad> o/
16:58:19 <lbragstad> heard keystone was giving you problems?
16:58:26 <lbragstad> how can i help?
16:58:45 <eglute> not problems exactly! we need a different test for one capability
16:58:59 <eglute> #link https://review.openstack.org/#/c/509638/
16:59:18 <eglute> basically, we need a test with one user, non admin
16:59:33 <markvoelker> This thing: https://github.com/openstack/interop/blob/master/2017.09.json#L1070-L1093
17:00:02 <markvoelker> I think we'll have to switch over to #openstack-interop though, we're out of time...
17:00:10 <lbragstad> ah - and this needs to be added to tempest?
17:00:21 <eglute> lbragstad correct
17:00:25 <lbragstad> before https://review.openstack.org/#/c/509638/ can actually be included as a requirement
17:00:50 <Rockyg> yup.  moving to 3openstack-interop
17:00:58 <markvoelker> Sorry gang, we need to yield the channel...
17:01:00 <markvoelker> #endmeeting