16:01:16 <Sukhdev> #startmeeting networking_ml2
16:01:17 <openstack> Meeting started Wed Jan  6 16:01:16 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:21 <openstack> The meeting name has been set to 'networking_ml2'
16:01:42 <Sukhdev> #topic: Agenda
16:01:47 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_January_6.2C_2016
16:02:00 <Sukhdev> #topic Announcements
16:02:23 <Sukhdev> Happy New Year
16:03:00 <Sukhdev> I have been away for a while and catching up -
16:03:35 <Sukhdev> M2 is next week, I believe
16:03:54 <Sukhdev> Anybody has any updates/announcements?
16:04:30 <Sukhdev> #topic: Driver API for SecurityGroup
16:04:47 <Sukhdev> #link: https://bugs.launchpad.net/neutron/+bug/1518087
16:04:48 <openstack> Launchpad bug 1518087 in neutron "[RFE] Method to guarantee that at least one mechanism driver implements security groups" [Wishlist,Won't fix] - Assigned to yalei wang (yalei-wang)
16:05:24 <Sukhdev> I was catching up on things last night and reviewed the comments by rkukura and armax
16:05:50 <rkukura> I just saw armax’s comment now
16:06:59 <Sukhdev> yalie : did you look at those comments as well?
16:07:26 <yalie> Sukhdev: yes, I saw the comments
16:07:56 <rkukura> I understand armax’s concern about avoiding unneeded complexity. I think the question is whether we need/want to support deployments where this sort of thing really is necessary.
16:07:57 <yalie> Sukhdev: I think armax don't like the coupling between MD's
16:08:38 <Sukhdev> yup - he does have a point though
16:09:37 <rkukura> Does anyone have an immiate need to deploy ML2 in scenarios where pre-deplyoment
16:09:59 <rkukura> where “pre-deployment validation” is not sufficient?
16:10:52 <yalie> I don't have one
16:11:04 <Sukhdev> neither do I
16:11:12 <rkukura> I guess I’m thinking of scenarios supporting both normal bindings where iptables works, and and things like ironic or sr-iov where it doesn’t
16:12:14 <yalie> rkukura: could you share ?
16:13:54 <rkukura> One simple case would be that a deployment includes normal compute hosts and sr-iov compute hosts, and binding in sr-iov should succeed only if no SG rules apply to the port.
16:15:25 <rkukura> If nobody has a short term need for this, I propose myself, yalie, and anyone else interested work up a detailed and general proposal for N, that covers enforcing semantics for SGs, QoS, and any arbitrary extension drivers that may be configured.
16:16:03 <Sukhdev> that sounds reasonable
16:16:16 <yalie> rkukura: yes, I will continue working on it
16:16:56 <rkukura> this item was on the to-do list for followup to the extension driver support being added, and I’m now convinced SGs need similar enforcement
16:17:21 <rkukura> But I’m OK with leaving this as “pre-deplyoment validation” for Mitaka
16:19:11 <Sukhdev> rkukura can you update the bug and bring it to a closure for the Mitaka?
16:19:24 <rkukura> ok
16:19:39 <Sukhdev> thanks
16:19:52 <Sukhdev> anything else on this?
16:20:01 <rkukura> do we have a name for N yet?
16:20:44 <Sukhdev> I tried to vote for it while back, the website was broken - do not know what transpired after that
16:21:01 <Sukhdev> were any of you able to vote for name for N release?
16:21:42 <rkukura> I had not received a ballot, asked, got one, but then it got burried in my inbox
16:21:55 <Sukhdev> :-)
16:23:16 <Sukhdev> It was in my inbox long time ago - I am sure now it is too late :-)
16:23:52 <Sukhdev> I will check after this meeting - unless somebody has answer
16:25:13 <Sukhdev> #action: rkukura and yalie to update the bug to get a closure on SG API for Mitaka
16:25:33 <Sukhdev> #topic: Vlan aware VMs
16:25:52 <Sukhdev> #link: https://review.openstack.org/#/c/243786/
16:26:15 <Sukhdev> I do not know if you have been following up on this or not
16:26:40 <Sukhdev> before I went on vacation, I had posted ML2 related issues/concerns on the patch
16:26:51 <rkukura> did they decide to add a new resource for this, or not?
16:28:11 <Sukhdev> I have to follow up with the author - but, I am not sure
16:28:39 <Sukhdev> It did not seem that there was much impact on ML2
16:29:03 <Sukhdev> I wanted to make sure that they call out appropriate work items in ML2
16:30:03 <rkukura> I cannot see how this would not have major impact on port binding.
16:30:05 <Sukhdev> No code has been posted yet, but, it is in the works
16:30:39 <Sukhdev> read kevinbenton's comments in response to my comment on this
16:32:22 <rkukura> Sukhdev: I’ll catch up on this ASAP
16:33:21 <Sukhdev> yup - read his comment posted on Dec 8 in reply to my comment about port-binding
16:34:36 <Sukhdev> #topic: limited portsec implementation
16:34:47 <Sukhdev> yalie : you are up
16:34:55 <yalie> yes
16:35:08 <Sukhdev> #link: https://review.openstack.org/#/c/250036/
16:35:10 <yalie> I tried to implement this limited-portsec
16:35:32 <yalie> within one existing extesnion port-security
16:36:11 <yalie> not sure if it is a good direction this time, welcome comments
16:37:05 <yalie> and a concern left is that I don't know to verify if the plugin support the limited-portsec or not.
16:37:53 <Sukhdev> yalie : what is the use case?
16:38:02 <yalie> currently limited-portsec should be a option within the port-sec, so if port-sec extension loaded, it is also loaded.
16:38:53 <yalie> Sukhdev: use case is that when the port don't have a ip address, we don't need a full port-sec which maybe based on IP
16:39:52 <yalie> Sukhdev: so we add a new attr for port within current port-security, which is limited-portsec
16:40:21 <Sukhdev> I see
16:41:18 <yalie> its value indicates that it works in diffenent domain, 'all' or 'l2only'
16:42:07 <Sukhdev> I was looking at the BP - there is not much information there - hence, was clarifying
16:42:43 <yalie> the previous version implemented with a individual extesnion, but there will be too much overlaping and relationship between it and existing port-sec
16:43:27 <yalie> so the lastest patch implement it in portsec.
16:44:20 <yalie> Sukhdev: yes, the BP most describe that work for support unaddress port, but not detailed.
16:45:32 <Sukhdev> thanks for the explanation - it makes sense now
16:45:54 <Sukhdev> I will go through now and review it
16:46:02 <yalie> Sukhdev: thanks!
16:46:24 <Sukhdev> anybody has any question on this?
16:46:36 <yalie> Sukhdev: if the direction is right, I will add UT on it.
16:47:56 <rkukura> yalie: Did you have a question about how to deal with plugins that inherit this exception but don’t implement the new attribute?
16:48:12 <rkukura> I meant “this extension” not “this exception”
16:49:12 <yalie> rkukura: yes
16:50:35 <yalie> rkukura: maybe detect the db schema?
16:50:35 <rkukura> Can you define a flag or function in the DB base class that needs to be overrriden by plugins when they support the new atttribute, and that by default raises exceptions when any value is set that limits the portsecurity?
16:51:07 <rkukura> yalie: I think you’ve added the new attribute to the existing DB base class, right?
16:51:30 <rkukura> If so, even unaware plugins will have the new schema
16:51:39 <yalie> rkukura: right, add new column in the exising table
16:52:13 <rkukura> so that’s why I was thinking of a flag in the base class that plugins need to override to enable the new functionality.
16:52:38 <yalie> rkukura: that's a good point
16:53:40 * Sukhdev time check 7 min
16:53:52 <yalie> I  will try to figure it out
16:54:36 <Sukhdev> anything else on this?
16:54:47 <rkukura> not from me
16:55:18 <yalie> last question the flag, rkukura
16:55:34 <rkukura> yalie: ?
16:56:20 <yalie> rkukura: if we use the flag, db base class need be updated to reflect the input arg, right?
16:56:46 <yalie> rkukura: I mean the obj init process will be updated.
16:57:32 <rkukura> I think the schema would be updated regardless of whether the plugin supports the attr, but the extension would reject setting the new attribute to anything but the default of the plugin doesn’t support it
16:58:48 <yalie> I see, thanks rkukura
16:58:49 <rkukura> I hate to mention it, but this is the kind of thing that gets complicated with ML2, if some MDs support it, and some don’t.
17:00:15 <Sukhdev> Folks we are out of time
17:00:31 <Sukhdev> lets take it on neutron channel -
17:00:49 <yalie> thanks all
17:00:57 <Sukhdev> Thanks for attending today's meeting - it was a very good discussion
17:01:00 <Sukhdev> bye
17:01:04 <Sukhdev> #endmeeting