17:00:47 <cathy__> #startmeeting service_chaining
17:00:48 <openstack> Meeting started Thu Apr 14 17:00:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:52 <openstack> The meeting name has been set to 'service_chaining'
17:00:52 <cathy__> hi everyone
17:01:06 <yamahata> hello
17:01:07 <LouisF> hi
17:01:29 <doonhammer> hi
17:01:31 <scsnow> hi
17:01:56 <cathy__> Let's start
17:02:12 <cathy__> #topic Meeting time change from Thursday 1700 UTC to Wednesday 1700 UTC
17:04:06 <cathy__> Russell Bryant who is the TC and Neutron core member would also like to join our IRC meeting, but the time conflict with OVN project IRC meeting. We would like him to join our meeting and give us guidance and input. Also some of us would like to join the OVN meeting for supporting integration of networking-sfc with OVN.
17:04:17 <cathy__> So is this time change OK with everyone?
17:04:24 <LouisF> +1
17:04:25 <doonhammer> good for me
17:05:00 <scsnow> this is one time change or permanent?
17:05:14 <cathy__> permanent
17:05:19 <yamahata> From the next week?
17:05:20 <scsnow> ok
17:05:29 <cathy__> yamahata: yes
17:05:59 <cathy__> pcarver: and others OK with you?
17:06:46 <cathy__> Please speak out if not OK with you:-)
17:07:57 <cathy__> Looks like Vikram is not on line yet.
17:08:56 <cathy__> I will communicate with those who are not on line yet. If not objection, we will change the time to Wednesday 1700 UTC starting next week. I will send an email confirming this
17:09:16 <cathy__> #agreed Meeting time change from Thursday 1700 UTC to Wednesday 1700 UTC
17:09:33 <cathy__> #topic Launch pad bug scrub
17:09:50 <cathy__> #link https://launchpad.net/networking-sfc
17:10:34 <cathy__> #link https://bugs.launchpad.net/networking-sfc
17:10:59 <cathy__> #1569009 remove "mandatory" restriction for "source port" in the Flow Classifier API
17:11:15 <cathy__> anyone would like to take ownership of this one?
17:11:57 <LouisF> I will look at that
17:12:08 <cathy__> LouisF: thanks
17:12:38 <cathy__> #1567654 Add “SFC path-ID” parameter in the chain_param of the API
17:12:55 <cathy__> Anyone?
17:13:04 <cathy__> I can take this one
17:13:24 <cathy__> #1567644 Add “Symmetric” parameter in the chain_param of the API
17:13:39 <scsnow> I could look into simple issues. I'm not really familiar with code yet, but would like to get involed.
17:13:51 <cathy__> scsnow: Thanks!
17:14:18 <cathy__> #1566877 network-sfc doesn't look started
17:15:29 <cathy__> The submitter is Jonathan Jacoby.
17:15:43 <LouisF> that is related to horizon support
17:16:08 <LouisF> can assign to mohankumar?
17:16:55 <LouisF> he was expecting to see SFC tab in horizon
17:17:01 <cathy__> LouisF: yes, you are right. I think once Horizon is merged this bug is gone since it asks for Horizon support
17:17:11 <cathy__> I think we can close this bug
17:17:42 <cathy__> #1564455 Neutron did not start - While Stacking
17:18:37 <georgewang> hi
17:18:41 <cathy__> This one was also submitted by Jonathan Jacoby. The note says "it works now, never mind". So I will close this bug
17:19:02 <cathy__> #1558020 API document have to modify as per changes introduced in flow classifier
17:19:06 <s3wong> hello. Sorry --- late
17:19:09 <fsunaval> cathy_: I can look into it.
17:19:19 <fsunaval> ok
17:19:43 <LouisF> i think that one can also be closed based on last comment
17:19:46 <cathy__> s3wong: OK, we are doing bug srub now.
17:19:51 <cathy__> scrub
17:19:55 <s3wong> cathy__: OK
17:20:30 <cathy__> fsunaval: Mohan has assigned the API document one to himself.
17:20:42 <cathy__> let's go to the next one
17:21:27 <cathy__> Mohan sent me a note that he can not join today
17:21:45 <cathy__> #1558012 incorrect error message for invalid argument in "neutron port-pair-group-create --port-pair"
17:23:00 <cathy__> looks like Mohan is looking into this bug, I will assign to him
17:23:41 <cathy__> #1557600 port-chain-delete failing as "SfcDriverError"
17:24:23 <LouisF> thats assigned to mohan
17:24:30 <cathy__> LouisF: yes
17:24:43 <cathy__> #1553886 remove-unwanted-dependencies
17:25:01 <cathy__> OK, Xiaodong is looking into this
17:25:24 <cathy__> #1538332 Port Pair Create fails for Provider Network
17:27:17 <cathy__> This one was submitted by Prithiv (prithiv). Not sure if the error still happens. Could anyone take this one?
17:27:44 <georgewang> I can take care bug 1538332
17:27:45 <openstack> bug 1538332 in networking-sfc "Port Pair Create fails for Provider Network" [Undecided,New] https://launchpad.net/bugs/1538332
17:28:08 <cathy__> georgewang: thanks
17:30:00 <cathy__> Ok, all other bugs seem to be in progress
17:31:18 <cathy__> #topic Raise a bug for each code change
17:31:43 <cathy__> Currently there are cases that a patch is submitted for review without an associated bug.
17:32:28 <LouisF> we should do that
17:32:48 <vishnoianil> +1 to that
17:32:55 <cathy__> I am going to scrub those offline and contact each patch owner to submit a bug for each patch so that we can track them properly for back porting purpose.
17:33:10 <cathy__> This issue was raised by Vikram.
17:33:38 <scsnow> should I open a bug of ongoing review https://review.openstack.org/#/c/302324/?
17:33:42 <s3wong> +1
17:33:45 <cathy__> From now on, let's follow the rule that each patch should have a bug for it
17:34:28 <cathy__> scsnow: sure. thanks.
17:34:41 <scsnow> ok, will do
17:34:58 <cathy__> #action Cathy will scrub all patches and make sure there is a bug associated with each patch
17:35:21 <cathy__> #action scsnow will open a bug for patch https://review.openstack.org/#/c/302324/?
17:36:15 <cathy__> #topic launchpad blueprint update/cleanup
17:36:53 <cathy__> #link https://blueprints.launchpad.net/networking-sfc
17:37:16 <cathy__> I will do some update on the BPs.
17:39:09 <cathy__> For the driver BP, I see the opendaylight-sfc-driver, we also need BPs for the ONOS-sfc-driver, Tacker-sfc-driver, native-OVS-sfc-driver and later OVN-sfc-driver
17:39:37 <cathy__> I will ask vikram/mohan to post the ONOS-sfc-driver BP
17:39:59 <cathy__> LouisF: could you add the tacker-sfc-driver BP?
17:40:22 <LouisF> yes
17:40:57 <LouisF> i will add a ovn bp also
17:41:10 <cathy__> raofei: could you add the native-ovs-sfc-driver BP?
17:41:17 <cathy__> LouisF: great, thanks!
17:41:41 <cathy__> #action vikram/mohan add ONOS-sfc-driver BP
17:42:14 <cathy__> #action LouisF adds tacker-sfc-driver BP and OVN-sfc-driver BP
17:42:44 <cathy__> #action Cathy update existing SFC BPs
17:43:50 <cathy__> OK, I will add the native-ovs-sfc-driver BP
17:44:02 <cathy__> #action Cathy adds native-ovs-sfc-driver BP
17:44:22 <cathy__> #topic Remove Source port “mandatory” requirement in the FC API
17:45:00 <cathy__> Based on email discussion we have agreed to remove the "mandatory" requirement for the "source port" in FC API.
17:46:26 <cathy__> We leave it to the SFC driver to decide whether requiring it or implementing its own way of automatically getting this source port.
17:46:46 <cathy__> any different opinion on this?
17:47:31 <cathy__> #agreed remove the "mandatory" requirement for the "source port" in FC API and leave it to the SFC driver to decide whether requiring it or implementing its own way of automatically getting this source port
17:47:39 <s3wong> +1
17:47:43 <LouisF> +1
17:47:58 <fsunaval> +1
17:48:18 <cathy__> #topic Consistent Repository rule for networking-sfc related drivers: Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
17:48:42 <cathy__> Shall we put all networking-sfc related drivers in networking-sfc repository?
17:49:25 <s3wong> cathy__: that is a good topic. I was actually wondering if vishnoianil should file ODL SFC driver under networking-sfc or networking-old
17:49:39 <s3wong> cathy__: now he filed patch under networking-odl
17:50:37 <cathy__> s3wong: yes
17:50:43 <cathy__> vishnoianil: are you there?
17:51:29 <cathy__> I guess the bug scrub topic makes people sleepy and people are not active today as before:-)
17:51:30 <yamahata> Since vishnoinail doesn't seem here.
17:51:40 <yamahata> networking-odl doesn't have strict policy.
17:51:45 <yamahata> It's case-by-case basis.
17:52:09 <yamahata> so sfc-odl-driver can be in networking-sfc or networking-odl
17:52:23 <cathy__> yamahata: OK, thanks for the info. I see vishnoianil joins the meeting
17:52:41 <cathy__> yamahata: OK.
17:54:19 <s3wong> cathy__: which way would you prefer?
17:54:19 <cathy__> I would like to make a consistent rule for all drivers. putting it in networking-sfc will help people see all the available drivers at a centralized place when they need SFC functionality. If we put the drivers in different repo, people will not know what SFC drivers are available
17:54:49 <cathy__> s3wong: I think putting them in one centralized place like networking-sfc probably makes more sense.
17:55:45 <LouisF> seems reasonable
17:55:47 <fsunaval> cathy__: I agree with you.  It makes most sense to keep all the drivers in networking-sfc.
17:55:52 <georgewang> sounds good
17:55:57 <s3wong> cathy__: I generally agree with that --- since networking-sfc is by itself a library depending on Neutron
17:56:27 <cathy__> yamahata: OK with you for odl-sfc-driver?
17:56:28 <LouisF> the onos driver is currently in a separate repo
17:56:43 <s3wong> cathy__: so, if networking-odl, for example, which I assume is another library on top of Neutron, also implements some APIs from networking-sfc, it would be awkward in terms of installation
17:56:59 <yamahata> cathy__: yeah. sounds reasonable. When patch review etc, please make sure add me.
17:57:15 <cathy__> yamahata: Ok, sure will do
17:57:37 <vishnoianil> cathy__, i personally think this should be in networking-odl project
17:58:00 <vishnoianil> cathy__, because networking-odl project is an integration point for OpenDaylight
17:58:50 <LouisF> onos driver https://github.com/openstack/networking-onos
17:59:30 <LouisF> we can speak to vikram about that
17:59:39 <cathy__> vishnoianil: I agree that networking-odl be in a separate repo. But odl-sfc-driver is an integration between networking-sfc and networking-odl which can be put in either repo
17:59:45 <cathy__> LouisF: yes
17:59:56 <vishnoianil> cathy__, LouisF , i see bit of confusion here for the folks who deploy openstack with opendaylight, they will see that some of the driver are in networking-odl, but for rest of the driver then need to go to specifc project
18:00:00 <yamahata> supplement. my position here is a coordinator. If the actual contributer, in this case, vishnoianil, has opinions, we should listen
18:00:06 <cathy__> I will speak with vikram offline since he is not in the meeting today
18:00:47 <vishnoianil> cathy__, given that all the driver project see networking-sfc as a API provider and not really a implementation provider
18:01:19 <vishnoianil> cathy__, we probably end up with the same issue that neutron had in it's earlier days and then they refactored the projects and moved out the specific drivers
18:02:21 <LouisF> vishnoianil: good point - depends on ownership
18:02:28 <vishnoianil> cathy__, maintaining these drivers in their own repos, will probably be more easy for the maintainer and also for networking-sfc project to avoid additional maintenance  head ache
18:02:31 <cathy__> vishnoianil: I think for controller case, most of the logic will be in ODL controller, not in the odl-sfc-driver?
18:03:08 <vishnoianil> yeah, so all the drivers are just pass through drivers, so having them in networking-odl make life easier for everyone
18:03:19 <yamahata> Is any (big) API change planed in near term?
18:03:34 <vishnoianil> cathy__, it does not make sense for ishaku to come and review a gerrit that is pushed to networking-sfc
18:03:35 <cathy__> vishnoianil: Ok, I see your point. time is up. Let's continue the discussion in next week IRC.
18:03:51 <vishnoianil> cathy__, for networking-odl driver :)
18:03:54 <vishnoianil> cathy__, sure
18:04:01 <s3wong> LouisF, cathy__, vishnoianil: I just wonder whether it is strange for networking-xxx to have reference to implement networking-sfc APIs while users may NOT load networking-sfc library
18:04:44 <cathy__> s3wong: good point.
18:05:17 <cathy__> Ok, folks, time is up. Let's think about about the consequence of this and discuss in next meeting
18:05:26 <LouisF> bye
18:05:27 <cathy__> Bye now
18:05:29 <scsnow> bye
18:05:30 <yamahata> bye
18:05:34 <s3wong> bye
18:05:35 <fsunaval> bye
18:05:43 <cathy__> #endmeeting