17:03:53 <pcarver> #startmeeting service_chaining
17:03:53 <openstack> Meeting started Thu Mar 17 17:03:53 2016 UTC and is due to finish in 60 minutes.  The chair is pcarver. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:56 <vikram> can we start our meeting
17:03:58 <openstack> The meeting name has been set to 'service_chaining'
17:04:05 <vikram> thanks pcarver
17:04:14 <johnsom> o/
17:04:24 <pcarver> This may be a short meeting, but we can open it up to anyone who has topics to discuss
17:04:48 <pcarver> There have been a few bug emails. I think from Mohankumar and Prithiv
17:05:02 <pcarver> are either of you here to discuss?
17:05:22 <pcarver> I don't recall their IRC handles off the top of my head
17:05:26 <vikram> i can't find anyone here...
17:05:59 <pcarver> it looked like a couple of low hanging fruit bugs
17:07:38 <pcarver> I'm looking at https://bugs.launchpad.net/networking-sfc right now to see what's there
17:08:18 <pcarver> I may pick up this doc bug if I can squeeze in the time https://bugs.launchpad.net/networking-sfc/+bug/1558020
17:08:19 <openstack> Launchpad bug 1558020 in networking-sfc "API document have to modify as per changes introduced in flow classifier" [Undecided,New]
17:08:56 <pcarver> This one also looks like an easy fix, just rewording an error message https://bugs.launchpad.net/networking-sfc/+bug/1558012
17:08:57 <openstack> Launchpad bug 1558012 in networking-sfc "incorrect error message for invalid argument in "neutron port-pair-group-create --port-pair"" [Undecided,New] - Assigned to Mohankumar (mohankumar-n)
17:09:26 <vikram> pcarver: I was thinking of removing source-port as mandatory param
17:09:47 <vikram> pcarver: IMO, flow-classifier should be generic
17:10:10 <pcarver> vikram: I agree, flow classifier should be generic
17:10:27 <vikram> pcarver: we should not tie sfc requirement on fc
17:10:57 <vikram> rather we can think of some other way handling src-port requirement
17:11:10 <vikram> *mandate requirement
17:12:50 <pcarver> doesn't sound like there's any argument on that
17:13:04 <pcarver> although there isn't really anyone here to argue :-)
17:13:13 <vikram> ;-)
17:14:32 <vikram> i was thinking of providing src-port info in the sfc-parameter rather than making it as a mandate field in fc
17:15:39 <vikram> let's wait working on this bug until we decide
17:15:57 <vikram> pcarver: what's ur feeling?
17:16:12 <pcarver> what was the reason why we need it? Is it specific to the OvS implementation or an intrinsic requirement of the API?
17:16:31 <pcarver> I'm thinking in terms of multiple backends implementing the same API
17:16:53 <pcarver> i.e. would Contrail or OVN or ODL also have it as a mandatory field?
17:17:20 <vikram> I don't think so ..
17:17:24 <vikram> with NSH in place
17:17:55 <vikram> AFAIK, we made it mandatory to distinguish the incoming traffic..
17:18:06 <vikram> on the other compute node..
17:18:07 <pcarver> So in thinking about the API in general, we need to think about how/where to handle things that are dependent on which driver is in use.
17:18:25 <vikram> yes
17:18:49 <vikram> that's why I said we can make it as a part of service-chain-parameter..
17:18:58 <vikram> if someone needs then they can define
17:19:00 <vikram> and act
17:19:17 <pcarver> which then leads to the question of discoverablity, if certain things are optional or mandatory depending on which driver, the API needs to make that discoverable.
17:19:18 <vikram> but definately not as a part of fc
17:19:33 <pcarver> I agree, not part of fc
17:20:24 <pcarver> I'm thinking now about the general question of how the API user can discover if a certain driver requires them to supply additional parameter(s) that another driver does not
17:20:32 <vikram> We need to give more thought on this
17:21:05 <vikram> I presume, admin must know the limitation
17:21:17 <vikram> and should configure accordingly
17:21:42 <vikram> all this issues will go off once we have NSH in place
17:22:50 <vikram> or respective driver MUST complain if they are not happy with the provided configuration
17:25:08 <vikram> I think we can have this discussion if more members are there ;-)
17:25:13 <vikram> let's move on
17:25:18 <pcarver> I agree
17:32:41 <pcarver> maybe there aren't any other pressing topics
17:33:45 <vikram> we can wind up then ;-)
17:34:41 <pcarver> ok. thanks
17:34:50 <pcarver> #endmeeting