17:00:35 <cathy_> #startmeeting service_chaining
17:00:37 <openstack> Meeting started Thu May  5 17:00:35 2016 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:41 <openstack> The meeting name has been set to 'service_chaining'
17:00:51 <cathy_> hi everyone
17:00:54 <LouisF> hi
17:00:58 <yamahata> hello
17:00:59 * regXboi wanders in and finds a seat in the corner
17:01:02 <igordcard> hi
17:01:38 <scsnow> hi
17:02:19 <fsunaval> hi
17:02:43 <cathy_> let's start
17:03:06 <mohankumar__> Hi cathy_
17:03:14 <cathy_> #topic Confirm the CI maintenance ownership
17:03:20 <cathy_> hi mohankumar__
17:03:39 <cathy_> In last meeting, this ownership is assigned to you, mohankumar__ . Is this OK with you?
17:03:56 <mohankumar__> Okay cathy_
17:04:09 <cathy_> mohankumar__: Thank you!
17:04:47 <pcarver> hi. sorry I'm going to be in  voice meeting simultaneous with this IRC
17:04:58 <cathy_> #topic Consistent Repository rule for networking-sfc related drivers: Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
17:06:31 <cathy_> I am thinking we should have a consistent rule as to where the SFC driver located.
17:07:07 <cathy_> Since the SFC driver is a piece connecting networking-sfc with another project, so it could reside in either repo.
17:07:22 <cathy_> Currently OVS driver resides in networking-sfc
17:07:25 <mohankumar__> cathy_:  agree
17:08:06 <yamahata> as FYI, networking-odl includes drivers for other services like fwaas, lbaas, l2gw etc.
17:08:41 <cathy_> yamahata: thanks for the info
17:08:42 <LouisF> networking-onos has a separate repo
17:09:03 <mohankumar__> Sfc Onos driver code kept n networking-onos
17:09:17 <LouisF> mohankumar__: correct
17:10:22 <LouisF> mohankumar__: networking-onos repo also has the ml2 support - right?
17:10:37 <mohankumar__> LouisF:  yes
17:10:47 <doonhammer> The prototype I did for OVN could all live under networking-sfc but I needed some extensions in networking-ovn not part of the OVN/SFC driver but an interface to OVN
17:11:17 <cathy_> doonhammer: OK, we can discuss the extension for OVN
17:11:27 <regXboi> so... that doesn't quite make sense - I would argue that networking-sfc should be the API and a reference implementaiton on ovs and let the other projects handle their own thing
17:11:45 <doonhammer> The sfc driver model worked very well - but perhaps we need another abstraction for the actual mechanism OVN, ONOS, ODL etc ?
17:11:48 <regXboi> because for example, networking-ovn is likely going to split into an ML2 and L3 service drivers
17:12:10 <regXboi> and having the SFC specific driver code in yet another project could slow velocity
17:12:19 <LouisF> regXboi: will that work be in separate repo?
17:12:26 <doonhammer> yes - not sure of the best approach
17:12:34 <regXboi> I believe that is planned for the networking-ovn repo
17:12:36 <regXboi> at least for now
17:13:15 <LouisF> regXboi: does having separate repos affect packaging?
17:13:35 <vishnoianil> regXboi, i agree with your thoughts
17:13:37 <regXboi> for our operations to date, no
17:13:51 <regXboi> but I won't speak for other folks there
17:13:58 <cathy_> I think probably the rule is that the repo team for the driver should be responsible for making sure to update the driver accordingly if there is any new update in either repo
17:15:09 <cathy_> For example, if there is a change in networking-sfc, then networking-sfc team will update the OVS driver if needed, but ODL team will be responsible for updating the SFC driver in ODL accordingly
17:15:25 <LouisF> cathy_: +1
17:15:40 <mohankumar__> cathy_:  yes +1
17:15:40 <regXboi> that makes sense
17:15:41 <yamahata> cathy_: that's quite reasonable.
17:15:48 <vishnoianil> cathy_, yes
17:16:30 <mohankumar__> We should document it somewhere , may with the driver owners
17:16:32 * regXboi now surfs OVN IRC meeting in parallel ... moves to multi-tasking mode
17:16:37 <cathy_> #agreed we agreed on the rule that the repo team for the driver should be responsible for making sure to update the driver accordingly if there is any new update in either repo
17:17:18 <cathy_> mohankumar__: yes, we should add this in the driver spec
17:17:39 <yamahata> If major/big change is expected, I expect it will be communicated in advance before merge.
17:17:40 <cathy_> mohankumar__: could you add this to the ONOS driver spec?
17:18:15 <cathy_> yamahata: yes, we will always discuss the change in the networking-sfc meeting
17:18:23 <mohankumar__> Yes cathy_ , will add
17:18:31 <cathy_> yamahata: could you add this rule to the ODL driver spec?
17:18:49 <yamahata> vishnoianil: can you do it?
17:19:56 <yamahata> cathy_: he seems away. Anyway I'll take care of it somehow.
17:20:10 <cathy_> #action mohankumar__ will add the driver updating rule to the ONOS sfc driver spec, yamahata will add the driver updating rule to the ODL sfc driver spec
17:20:35 <cathy_> Let's go to next topic
17:20:36 <vishnoianil> yamahata, sure
17:20:44 <cathy_> #topic Requriement for reference Implementation on OVS driver and OVS Agent path for any API extension
17:22:43 <cathy_> We do not want an API extension without corresponding implementation. But I understand that it might take long for the implementation to be completed. And we should not block merge of an API change for a long time.
17:22:51 <cathy_> Any suggestion on how to resolve this?
17:23:14 <pcarver> cathy_: I think we should start with a spec
17:23:22 <scsnow> I think it's better to add spec and blueprint to pass API change
17:23:25 <LouisF> cathy_: are you refering to adding say the symmetric attribute?
17:23:36 <cathy_> LouisF: yes
17:23:42 <fsunaval> or l2 option for that matter ?
17:23:47 <cathy_> pcarver: Yes, spec and BP are fine
17:23:49 <pcarver> If we discuss and merge a spec for a new API extension then we can figure out who's going to add the API and implemetation code
17:23:53 <igordcard> cathy_: but is that an API change?
17:24:29 <pcarver> The change to the API code and dataplane implementation should be close in time, but perhaps don't have to be simultaneous
17:24:35 <LouisF> igordcard: depends on the definition of an api change
17:24:39 <cathy_> pcarver: but my concern is that once we approve the spec for the API extension, but no implementation is done
17:24:51 <cathy_> I mean no reference implementation is done
17:25:02 <pcarver> cathy_: we should try to model after Neutron process
17:25:19 <cathy_> pcarver: Yes, could you clarify the process?
17:25:31 <pcarver> targetting blueprints but bumping them out if it doesn't look like implemnetation will meet a milestone
17:25:47 <cathy_> fsunaval: yes, l2/l3 is another extension that is being proposed by people
17:25:52 <fsunaval> cathy_ : Sometimes we might not be able to do the reference implementation with OVS or it would take a lot more effort with OVS than with OVN (for example)
17:25:52 <pcarver> cathy_: blueprints are targetted at milestones
17:26:10 <pcarver> they can slip and get bumped out to a later milestone or to a later release
17:27:31 <mohankumar__> pcarver:  exactly +1
17:28:28 <cathy_> pcarver: yes, I am thinking the same when we merge a spec for a new API extension, we should make sure someone is going to add the API and reference implementation code on the OVS driver path
17:29:17 <pcarver> cathy_: the spec would be tied to a blueprint I think
17:29:57 <cathy_> pcarver: what specific mechanism do you mean by "the spec tied to the BP"?
17:31:50 <pcarver> The BP usually references a spec review
17:31:56 <pcarver> as well as implementation reviews
17:32:02 <mohankumar__> One BP can have multiple spec
17:32:27 <pcarver> I'm not sure if there's a rule on when a spec can be merged vs when code is merged
17:34:13 <pcarver> I think Neutron also maintains different spec directories for each cycle unless that has changed
17:34:44 <pcarver> I believe that a spec can be moved out of the Mitaka directory to Newton directory for example
17:35:21 <cathy_> pcarver: I think what we can do to enforce the reference implementation is to identify the owner of the API spec and related implementation. If an implementation is not in place at the targeted milestone, the spec will be moved out to a later release.
17:35:24 <LouisF> yes https://github.com/openstack/neutron-specs/tree/master/specs/newton
17:37:22 <cathy_> LouisF: looks like a spec can be moved from one release to another release, right?
17:37:45 <regXboi> it not only can, it should
17:38:10 <LouisF> cathy_: separate release dirs exist - its up to the team on their usage
17:38:26 <LouisF> regXboi: +1
17:40:25 <cathy_> #agreed to enforce the reference implementation for an API extension, the owner of the API spec and related implementation needs to be identified before the spec can be merged. If the implementation is not in place at the targeted milestone, the spec will be moved to the next release
17:41:49 <cathy_> #topic Add support for Querying Driver capability for SFC functionality support
17:43:03 <cathy_> This is a good suggestion by Paul Carver. Anyone would like to own this?
17:43:21 <scsnow> Any details what is that?
17:43:42 <LouisF> pcarver: can you give an example?
17:43:53 <pcarver> This is related to the idea that not all drivers may be able to implement all capabilities of the API
17:44:05 <pcarver> e.g. symetric reverse flow hashing
17:44:13 <regXboi> so... isn't this microversioning and GET / ?
17:44:32 <pcarver> There ought to be a mechanism for a driver to indicate that it can't provide a capability so that the API can let the client know
17:45:04 <pcarver> and it would be better to be able to discover capabilities in advance rather than by just trying to make an API call and getting a failure response
17:45:19 <cathy_> pcarver: 100% agree
17:45:33 <LouisF> pcarver: does neutron support this currently?
17:45:35 <regXboi> I repeat... isn't this microversioning and GET / ?
17:45:48 <regXboi> and IIRC, not yet - I'm looking for the LP bug
17:45:55 <pcarver> LouisF: I'm not sure in general, but something along this line was discussed specifically around VLAN transparency
17:46:14 <igordcard> a question, all these capabilities to be queried to the driver - will they be capabilities already standardized inside chain_parameters, or could it be any other "string" passed to chain_parameters?
17:46:53 <regXboi> all... see https://bugs.launchpad.net/neutron/+bug/1577410 for the test against Neutron
17:46:54 <openstack> Launchpad bug 1577410 in neutron "Neutron needs a test for GET /" [Low,Triaged] - Assigned to Mark T. Voelker (mvoelker)
17:46:57 <pcarver> igordcard: I think we'd probably need to enumerate somewhere. I don't know if it could be totally open to runtime
17:47:02 <igordcard> that would then be queried to the driver (which might my own homebrewed driver)
17:49:17 <scsnow> Do we have a list of capabilities, that driver should report?
17:50:26 <scsnow> Per my understanding that's something different to microversions
17:51:06 <cathy_> regXboi: from reading https://bugs.launchpad.net/neutron/+bug/1577410, it seems the GET is for a specific release version's API capability, not a specific  backend driver capability. My understanding may be wrong.
17:51:08 <openstack> Launchpad bug 1577410 in neutron "Neutron needs a test for GET /" [Low,Triaged] - Assigned to Mark T. Voelker (mvoelker)
17:51:39 <cathy_> scsnow: yes, I think the same
17:51:44 <regXboi> Yes, but I'm asking why that same idea can't be leveraged
17:52:23 <igordcard> in my opinion the capabilities reported should be up to what different possible chain_parameters are supported in the API itself
17:52:30 <LouisF> there should be a general solution for all apis not just networking-sfc
17:53:25 <cathy_> regXboi: Yes, it is similar idea. But we need some ownership to implement this idea (could leverage whatever available in Openstack).
17:54:32 <regXboi> There was a design session on the Neutron API in ATX that included microversioning, but I don't remember how it came out...
17:54:43 <scsnow> I could help with implementation, but currently I don't fully understand the idea
17:55:09 <scsnow> So I expect that someone could help with spec
17:55:30 <cathy_> scsnow: I don't think we will define what API capability a driver should support as long as it supports the basic chain capability
17:55:40 <regXboi> I agree with LouisF that the solution should be general
17:56:03 <cathy_> scsnow: sure, I can hep you with the spec.
17:56:38 <igordcard> cathy_: so is the correlation type mpls part of the basic chain capability?
17:57:02 <cathy_> scsnow: thanks for taking this ownership. You may need to do some investigation on microversioning that regXboi mentioned to see if there is any work we can leverage
17:57:21 <cathy_> igordcard: no
17:57:45 <igordcard> ok
17:57:58 <regXboi> are we to the open mike part of the agenda yet?
17:58:49 <scsnow> I familiar with nova microversioning and know how to deal with it. So I'll take a look how things are done in neutron.
17:59:07 <cathy_> regXboi: not yet. We are going through the topics listed in the meeting agenda of the project wiki page.
17:59:21 <regXboi> scsnow: be warned - afaik, it's not *there* yet
17:59:24 <cathy_> scsnow: great! thanks
18:00:13 <scsnow> regXboi, yes, I see
18:00:26 <cathy_> #agreed scsnow will take ownership of the "Add support for Querying Driver capability for SFC functionality support" work. Cathy will help with the spec.
18:00:45 <cathy_> time us up. We will continue our discussion next week.
18:00:51 <cathy_> Thanks everyone. bye now
18:00:53 <LouisF> bye
18:00:53 <scsnow> bye
18:00:57 <igordcard> bye
18:00:58 <mohankumar__> Bye
18:01:00 <yamahata> bye
18:01:00 <doonhammer> bye
18:01:05 <cathy_> #endmeeting