17:02:24 <LouisF> #startmeeting service_chaining
17:02:25 <openstack> Meeting started Thu Dec 15 17:02:24 2016 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:28 <openstack> The meeting name has been set to 'service_chaining'
17:02:35 <LouisF> hi all
17:02:39 <pcarver> hi
17:02:44 <bcafarel> hi
17:02:52 <doonhammer> Hi LouisF
17:04:26 <LouisF> agenda for today https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.2812.2F15.2F2017.29
17:04:54 <LouisF> #topic big stadium work
17:05:20 <LouisF> api reference
17:05:40 <LouisF> pcarver: thanks for the patch update
17:05:41 <pcarver> I just split out the API definition from the API reference
17:06:11 <pcarver> I think the API reference is just about done, but the API definition is turning out to be more complicated than I expected
17:06:50 <pcarver> One question on the API reference though. Is tenant_id a valid field in a request?
17:07:06 <pcarver> I was thinking about whether an admin can make a request on behalf of a tenant
17:07:48 <LouisF> pcarver: that could be a possible scenario
17:08:03 <pcarver> If a tenant makes a request they shouldn't have to supply their tenant ID in the request body, but I'm not sure about the admin scenario.
17:09:01 <mohankumar> hi
17:09:07 <LouisF> pcarver: what are the issues with the api definition?
17:09:10 <LouisF> mohankumar: hi
17:09:44 <pcarver> I took the tenant_id field out of the request sections of the api-ref, but I've been having issues with getting SFC to work in devstack lately so I haven't tested it yet.
17:10:22 <LouisF> pcarver: ok thanks
17:10:32 <pcarver> The issue with the API definition is that it uses custom validators and one of the validators uses an SFC specific exception so I had to copy those into neutron-lib as well. However, there are objections to that.
17:11:01 <pcarver> So I need to do some more work with the SFC exceptions and validators before I can make the API definition acceptable.
17:11:36 <pcarver> I can't just import them from where they currently are because that would make neutron-lib depend on networking-sfc
17:11:54 <bcafarel> which I suspect won't be accepted by neutron-lib folks
17:11:55 <pcarver> which is not desirable. We want networking-sfc to depend on neutron-lib, but not the other way around.
17:12:14 <LouisF> pcarver: yes
17:12:45 <pcarver> So I'll get the validators and exceptions straightened out. I just didn't want it in the same commit.
17:13:03 <pcarver> The api-ref commit was originally just supposed to be documentation
17:13:12 <LouisF> pcarver: right
17:13:34 <pcarver> I added in the API definition because I thought it was just a simple matter of some copy and paste into neutron-lib
17:13:56 <pcarver> but since it's a bit more than simply copy/paste I'd like to decouple it from the documentation commit
17:14:48 <LouisF> pcarver: ok
17:16:17 <LouisF> mohankumar: what is status of cli port?
17:16:32 <LouisF> https://review.openstack.org/#/c/409759/
17:18:26 <LouisF> please review this patch
17:19:18 <LouisF> mohankumar: there are few comment on it
17:19:42 <mohankumar> LouisF: yes
17:19:51 <mohankumar> Working on it
17:20:21 <LouisF> mohankumar: thanks
17:20:54 <LouisF> moving on
17:21:05 <LouisF> #topic current work items
17:22:28 <LouisF> fix flow deletion unit tests https://review.openstack.org/#/c/411194/
17:22:39 <LouisF> bcafarel: thanks for your work
17:23:17 <LouisF> enable pep8 test everywhere https://review.openstack.org/#/c/411387/
17:23:29 <LouisF> bcafarel: thanks also
17:23:35 <LouisF> please review these
17:23:50 <bcafarel> LouisF: np, just giving you some more review work :)
17:25:13 <LouisF> move db migration tests to functional tests https://review.openstack.org/#/c/410818/
17:26:28 <LouisF> use project_id instead of tenant_id in DB models/OVS driver https://review.openstack.org/#/c/409162/
17:26:36 <LouisF> please review these
17:27:52 <LouisF> Use ovs devstack plugin functions from neutron https://review.openstack.org/#/c/409800/
17:29:07 <LouisF> Replaces uuid.uuid4 with uuidutils.generate_uuid() https://review.openstack.org/#/c/396129/
17:29:58 <LouisF> Validate all flow-classifier parameters while creating port-chain https://review.openstack.org/#/c/409771/
17:30:08 <LouisF> priya: thanks for your work
17:30:35 <priya> will update the unit tests
17:30:38 <LouisF> priya: can you address the comments
17:30:42 <LouisF> priya: thanks
17:31:48 <LouisF> Revert "Using --strict and add priority for del_flows" https://review.openstack.org/#/c/406938/
17:32:19 <LouisF> bcafarel: is this still needed?
17:33:01 <pcarver> should it be "use project_id instead of tenant_id" of "use project_id in addition to tenant_id"?
17:33:02 <bcafarel> LouisF: should not with https://review.openstack.org/#/c/411194/
17:33:10 <pcarver> s/of/or/
17:33:28 <pcarver> i.e., should tenant_id be removed at this time?
17:33:53 <LouisF> bcafarel: ok thanks
17:34:08 <bcafarel> I recall Igor mentioning problems with flow deletions, but I am not sure if it was related to this change (anyway this can be done in a later review)
17:34:27 <LouisF> bcafarel: ok
17:35:04 <bcafarel> pcarver: it is mostly internal use, so the real field is project_id
17:35:19 <LouisF> bcafarel: right
17:35:28 <pcarver> bcafarel: I was asking mainly in reference to the api-ref I'm working on.
17:35:34 <pcarver> Should tenant_id be deleted?
17:35:41 <pcarver> Or should both be shown?
17:36:10 <bcafarel> hmm it is going away and there is some magic in the CLI to accept both
17:36:37 <bcafarel> I am not sure what should be shown in doc (like listing tenant_id but as deprecated)
17:37:31 <LouisF> can investigate further
17:38:25 <LouisF> symmetric port chain for ovs driver/agent patch https://review.openstack.org/#/c/410482/
17:38:31 <LouisF> please review
17:38:57 <LouisF> #topic ocata work
17:39:01 <bcafarel> pcarver: we probably can do something like in neutron http://developer.openstack.org/api-ref/networking/v2/#tenant-and-project-attributes-in-requests
17:39:40 <pcarver> bcafarel: that's what I was thinking
17:39:56 <pcarver> in the latest patch set of the api-ref I added project_id but did not delete tenant_id
17:40:07 <LouisF> pcarver: looks like a good approach
17:40:13 <pcarver> They would always be expected to be identical, but the API would return both
17:43:30 <LouisF> sfc graph work is under way https://review.openstack.org/#/c/388802/
17:44:03 <LouisF> symmetric port chain for ovs in review
17:44:53 <LouisF> todo ovn driver work
17:45:26 <doonhammer> little progress - swamped with another project
17:45:37 <LouisF> anyone interested in this contact myself or John
17:45:42 <doonhammer> I am trying to carve out some time but hard
17:45:51 <LouisF> doonhammer: ok
17:45:57 <doonhammer> happy to help someone else to come up to speed
17:46:02 <doonhammer> and participate
17:46:40 <LouisF> i have another meeting and will end meeting
17:46:55 <LouisF> anything else for next week?
17:47:28 <bcafarel> LouisF: yes, stable newton branch
17:48:00 <bcafarel> there is a bug open from people who tried it and got the ovs build failure, plus pending patches blocked as the gates fail for stable branch
17:48:30 <bcafarel> please review https://review.openstack.org/#/c/406152/ to unblock these
17:48:37 <LouisF> bcafarel: ok thanks
17:48:54 <bcafarel> it's mostly a backport of tests fixes, plus configuration updates to pick the correct branch
17:49:58 <LouisF> bcafarel: will do
17:50:12 <bcafarel> LouisF: thanks!
17:50:55 <LouisF> thanks all
17:51:04 <LouisF> bye
17:51:09 <LouisF> #endmeeting