16:08:19 <rkukura> #startmeeting networking_ml2
16:08:19 <openstack> Meeting started Wed Apr 19 16:08:19 2017 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:08:23 <openstack> The meeting name has been set to 'networking_ml2'
16:08:48 <rkukura> Looks like we have at least /me, Sukhdev, dasanind, and trevormc
16:08:50 <rkukura> Anyone else?
16:09:34 <rkukura> #topic Agenda
16:09:51 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_19.2C_2017
16:09:59 <rkukura> Similar agenda to recent meetings.
16:10:05 <rkukura> Anyone have anything to add or remove?
16:10:41 <rkukura> Guess not…
16:10:51 <rkukura> #topic Announcements
16:11:18 <rkukura> Only thing I can think of is that the Boston summit is approaching
16:11:27 <rkukura> Any other announcements?
16:12:28 <rkukura> #topic Bugs/RFEs
16:12:54 <rkukura> Any new (or old) bugs to discuss?
16:14:16 <rkukura> One RFE we should discuss is the one I filed a while back about enforcing extension semantics
16:14:20 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1673142
16:14:21 <openstack> Launchpad bug 1673142 in neutron "[RFE][ML2] Enforce extension semantics" [Wishlist,Confirmed]
16:15:15 <rkukura> So this is something I would have liked to implement for Pike, but have not had any time available.
16:15:41 <rkukura> I’m not sure that will change in the next couple months either, so if there is anyone else interested in picking it up, I’d be happy to discuss it with them in more detail
16:16:25 <rkukura> If not, we can try to figure whether to move forward with it at the Boston summit.
16:16:35 <rkukura> Any comments or questions on this one?
16:17:33 <Sukhdev_> rkukura : I think we should discuss this in Boston - and see the interest level
16:17:42 <rkukura> OK, any other RFEs to discuss?
16:17:50 <rkukura> Sukhdev_: agreed
16:18:15 <rkukura> #topic QinQ
16:18:54 <rkukura> #link https://review.openstack.org/#/c/446047
16:19:09 <rkukura> trevormc’s patch seems to be in pretty good shape, with active reviews
16:19:15 <trevormc> i just refactored the patch to re-use the vlan_allocation logic.
16:19:42 <rkukura> trevormc: great! Will you be posting that update soon?
16:19:48 <trevormc> done
16:20:13 <trevormc> the patch was updated 4 minutes ago :)
16:20:22 <rkukura> just look again - thanks!
16:20:45 <rkukura> I still have not found time for a detailed review, but I will try in the next day or two
16:21:05 <trevormc> are we ok with storing c_tags as a string?
16:21:20 <trevormc> We were hoping to put a single c_tag_range in here. <c_tag_min>:<c_tag_max>
16:21:23 <rkukura> Sukhdev_, I know you’ve looked at this
16:21:31 <trevormc> That would be a max of 9 characters, ex 4000-4001. So we can change the string size to 9.
16:22:36 <rkukura> trevormc: I really can’t comment until I review the patch more closely, but I have seen the comments related to these being strings
16:22:46 <Sukhdev_> trevormc : yes I looked at the previous version and was in the middle of reviewing it now - going over Kevin's comments - which are minot
16:22:50 <Sukhdev_> minor
16:23:41 <Sukhdev_> trevormc : kevinbenton is asking in the comments as to why is it a string and not integer -
16:24:47 <trevormc> Sukhdev_: I don't see why not.
16:25:06 <Sukhdev_> trevormc : I will go with integer - they both represent a number -
16:26:40 <trevormc> ok, do you think I need to add other tests? like fullstack/test_connectivity.py ?
16:27:45 <trevormc> here they create scenarios, https://github.com/openstack/neutron/blob/master/neutron/tests/fullstack/test_connectivity.py#L111
16:28:56 <Sukhdev_> trevormc : right - it will be a good idea, if you can add to this -
16:29:22 <Sukhdev_> trevormc : but, you do not have to do this as part of this patch - that can come as a separate patch
16:29:42 <trevormc> ok seperate patch it is, for easier review :)
16:29:53 <rkukura> seems reasonable to me
16:29:54 <trevormc> or would it be easier if I added them?
16:30:02 <Sukhdev_> trevormc : I would think it will be optional, but, I will leave it up to you
16:30:14 <trevormc> ok ill try.
16:30:14 <rkukura> yes, either way seems reasonable
16:30:42 <rkukura> anything else on the QinQ effort?
16:30:50 <trevormc> no
16:31:05 <Sukhdev_> trevormc : I do not see QinQ as core functionality like VLANs, etc.. - hence I think it is optional
16:31:59 <Sukhdev_> trevormc : tempest tests are necessary though
16:32:15 <trevormc> ok i was thinking about that, I would need a client patch too then.
16:32:56 <Sukhdev_> trevormc : do not add anything additional to this patch - keep the patches simpler
16:33:22 <rkukura> trevormc: silly question, but is the QinQ type driver all thats needed, or are there other patches adding support to the OVS agent, etc?
16:34:05 <trevormc> rkukura: not silly at all. I believe there are some required changes in the OVS agent.
16:34:38 <rkukura> so would these be needed for fullstack connectivity tests to succeed?
16:35:02 <trevormc> probably. Something like this https://review.openstack.org/#/c/342755/5/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
16:35:33 <rkukura> if so, I’d think we need to agent support first
16:35:49 <rkukura> are you planning to implement the agent support?
16:36:45 <trevormc> rkukura, I suppose I could. It wasn't planned but i don't think it will require much effort since there is work in the area already
16:38:11 <rkukura> My memory from discussing this in Atlanta is kind of hazy - was this NFV-specific?
16:38:23 <Sukhdev_> trevormc : how are you testing without agent changes? - using some kind of dedicated back-end?
16:38:27 <rkukura> Or part of some other effort?
16:39:24 <trevormc> rkukura: At AT&T we have a driver that allows us to do QinQ with SR-IOV. To support that we need the QinQ driver first.
16:39:50 <rkukura> OK, forgot this was related to SR-IOV
16:40:19 <trevormc> Sukhdev_: I was not sure what testing is required. I just try to create a network and if it succeeds then it works!
16:40:20 <rkukura> Is there any reason generic support in the OVS agent wouldn’t make sense?
16:41:28 <trevormc> rkukura: I believe the reason that was not merged is because they wanted a driver like the QinQ one i'm proposing now rather than the generic support.
16:41:37 <trevormc> https://review.openstack.org/#/c/342755/5
16:42:42 <rkukura> I see
16:44:22 <rkukura> I’d certainly prefer to see the OVS agent support and the fullstack tests eventually implemented
16:44:35 <Sukhdev_> trevormc : there is more than just create network :-):-) Don't you need to ensure the tagging and encoding/decoding takes place correctly - that is what rkukura was asking I think
16:45:18 <rkukura> right
16:46:20 <trevormc> Sukhdev_: yes that's true. The OVS agent should be able to do that. But The code hasn't been released yet.
16:46:43 <trevormc> to be released in 2.8
16:46:45 <trevormc> https://github.com/openvswitch/ovs/commit/f0fb825a3785320430686834741c718ff4f8ebf4
16:46:51 <trevormc> https://github.com/openvswitch/ovs/commit/fed8962aff57f552163ef718cc1b0db582f2295e
16:48:33 <rkukura> OK, I was not aware that OVS itself did not yet support QinQ. I guess we can revisit adding support to the openvswitch-agent once OVS 2.8 is available.
16:48:49 <trevormc> Should be in august
16:50:10 <rkukura> OK, maybe something to discuss in Boston, but seems like we can merge the type driver patch now and deal with fullstack connectivty testing later when the OVS support is there.
16:50:39 <rkukura> Anything else on this patch and its followon work?
16:51:11 <trevormc> The drivers team did not like the rfe I have for sr-iov
16:51:35 <rkukura> #topic SR-IOV port extension RFE
16:51:41 <trevormc> They say a lot of what I was asking for can be derived from existing APIs.
16:52:17 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1662650
16:52:19 <openstack> Launchpad bug 1662650 in neutron "[RFE] Advance configuration of SR-IOV ports- api extension" [Wishlist,Triaged] - Assigned to Trevor McCasland (twm2016)
16:52:35 <trevormc> I left a comment on the bug with a table to try and map the functionality to what is being requested.
16:53:16 <trevormc> Traffic protection is not implemented but the drivers team it should land in secgroups instead of a vf_policy api for example
16:53:58 <trevormc> however, the OVS firewall does not work with SR-IOV so there is no way to invoke the rules with the agent.
16:55:20 <rkukura> trevormc: Where is the feedback from the drivers team?
16:55:39 <trevormc> the log from last week, one sec
16:56:00 <trevormc> http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2017-04-13.log.html#t2017-04-13T22:14:14
16:56:03 <rkukura> thanks
16:56:20 <rkukura> we only have 5 minutes left, so maybe we should pick this up next week
16:57:01 <trevormc> agreed
16:58:28 <rkukura> #topic Open Discussion
16:58:42 <rkukura> Anything anyone would like to squeeze into the last two minutes?
16:59:15 <Sukhdev_> nothing from me -
16:59:24 <rkukura> If, not lets wrap up
16:59:25 <dasanind> rkukura: I need somebody to take over the multiple portbinding patch
16:59:41 <rkukura> dasanind: Was hoping to get to that today
16:59:58 <rkukura> dasanind: Can you join us next week to discuss?
17:00:15 <dasanind> rkukura: sure
17:00:43 <rkukura> Lets put that at the top of the agenda, followed by the SR-IOV RFE
17:00:49 <rkukura> thanks everyone!
17:00:52 <dasanind> Thank you
17:00:57 <rkukura> #endmeeting