16:02:51 <Sukhdev> #startmeeting networking_ml2
16:02:52 <openstack> Meeting started Wed Nov 26 16:02:51 2014 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:55 <openstack> The meeting name has been set to 'networking_ml2'
16:03:14 <Sukhdev> #topic: Agenda
16:03:30 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:03:54 <Sukhdev> #topic: Announcements
16:04:03 <Sukhdev> Two announcements -
16:04:26 <Sukhdev> There is mid-cycle code sprint in first week of Dec
16:04:40 <Sukhdev> https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint
16:05:01 <mlavalle> Sukhdev: it is actually the second week :-)
16:05:18 <Sukhdev> Some of the folks from this sub-committee are participating - feel free to sign up if you can spare time
16:05:27 <Sukhdev> mlavalle: thanks for correcting me
16:05:38 <Sukhdev> It is Dec 8-10
16:06:01 <Sukhdev> Kilo release schedule is out -
16:06:05 <Sukhdev> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
16:06:28 <Sukhdev> Anybody have any other announcements?
16:06:38 * Sukhdev takes a pause
16:07:09 <Sukhdev> #topic: Action items from last week
16:07:29 <Sukhdev> We have two items on agenda - based upon last week's discussions.
16:07:39 <Sukhdev> Hope the owners are present
16:08:12 <irenab> hi, sorry for being late
16:08:16 <Sukhdev> #topic: Rate limit discussion (QoS)
16:08:32 <irenab> I wanted to raise this topic
16:08:35 <Sukhdev> irenab: please take the stage and explain
16:09:06 <irenab> What we plan in relation to SR-IOV is to enable setting of rate limit per SR-IOV VF, which is neutron port
16:09:40 <irenab> Initially considered to use already proposed patches for QoS (by Sean Collins)
16:10:11 <irenab> But actually it is more than we need for SR-IOV. So another alternative is ML2 extension
16:10:48 <irenab> Ability to set rate limit on neutron port
16:11:14 <Sukhdev> irenab: do you have spec/BP for this?
16:11:51 <irenab> Not yet, probably next week. So the first question is what would you guys suggest regarding the API
16:12:20 <irenab> QoS Extension or Ml2 port rate limit extension
16:12:39 <irenab> Does it makes sense for other ML2 drivers as well?
16:13:47 <irenab> the second question is regarding get_device_details extention to propogate additional value (from port extension)
16:13:53 <Sukhdev> rkukura: is this being addressed through the policy framework which you have been working on?
16:14:22 <rkukura> Sukhdev: Not in GBP, if that is what you are refering to
16:14:43 <Sukhdev> rkukura: yes referring to GBP
16:15:06 <rkukura> The 2nd phase of the extension driver work would address making sure the limit, if set, was enforced by the port binding, even if some drivers didn’t understand it.
16:15:07 <Sukhdev> irenab: please go on
16:15:24 <rkukura> But we haven’t decided whether that will go in kilo or not.
16:16:00 <irenab> rkukura: can you please elaborate on what is 2nd phase
16:16:51 <irenab> I am talking about tx_rate_limit and bw_guarantee for traffic, not for neutron resources
16:17:03 <rkukura> irenab: 1st phase was in juno and enabled extension drivers to define attributes on core resources
16:17:29 <rkukura> but nothing guarantees the port binding provide the semantics implied by the values of those extended attributes
16:17:40 <rkukura> evolving ML2 to enforce those semantics is the 2nd phase
16:18:14 <rkukura> irenab: These would be extended attributes on the port resource, wouldn’t they?
16:18:23 <irenab> rkukura: yes
16:18:42 <irenab> And seems this is already possible with phase 1
16:19:09 <rkukura> Its possible as long as all configured MDs that can bind understand the extension
16:19:11 <irenab> What is required is to propagate the value to L2 agent on compute node to enforce it
16:19:58 <rkukura> irenab: Sounds like the MD that understands the extension and binds the port would need to pass the info to the agent, right?
16:20:08 <irenab> rkukura: I see. So this maybe a problem to mix then if not all understand the extension?
16:20:37 <rkukura> So we probably need to have the get_device_details call into the bound MD(s) as we had discussed a while ago.
16:21:05 <rkukura> We seem to need two things: 1) the ability for the MD to propagate the info to the agent (or controller or whatever)
16:21:06 <irenab> rkukura: This is exactly what I had in mind
16:21:25 <rkukura> and 2) the framework to make sure the port  binding enforces the extension semantics
16:21:59 <irenab> rkukura: or ignores it if not relevant
16:22:05 <rkukura> We can live without 2 as long as the deployment only configures MDs that understand the EDs that are configured.
16:22:29 <matrohon> i'm +1 on using get_device_detail to propagate extensions info!
16:22:33 <rkukura> irenab: agreed - that’s why the proposal is to let the ED decide whether the value requires enforcement
16:22:43 <rkukura> +1
16:23:11 <irenab> So on the general approach, seems beter go with ML2 extension?
16:23:37 <rkukura> Is the QoS work going forward in kilo?
16:23:44 <rkukura> Or is it on hold?
16:24:19 <irenab> I talked to Sean, and seems he is not optimistic regarding this in Kilo with all rework in general
16:24:45 <matrohon> I understood that sc68al proposal will be merged with only rate_limiting
16:24:48 <irenab> I tend to choose dedicated ML2 extension
16:25:11 <irenab> matrohon: I do not think he resubmitted this spec for Kilo
16:25:39 <matrohon> salv-orlando proposed to rename it rate-limiting extension!
16:25:50 <virtuallynathan_> is there a link to the proposal?
16:26:02 <matrohon> irenab: me neither :(
16:26:35 <matrohon> it was an agreement during friday afternoon design session, so no etherpad
16:26:42 <irenab> but in ML2 area, we still need ML2 extension for binding port and QoS policy
16:26:54 <salv-orlando> folks, if you wish it to be included in the kilo release cycle you need to resubmit the spec… it’s not a bureaucratic thing, it’s that we need to assess priorities also according to how are active are the various work items
16:27:27 <virtuallynathan_> matrohon: ah ok
16:27:52 <salv-orlando> also I suggested rate limiting because QoS was attracting so much interest that it became something impossible to define. And definetely something a lot bigger than what we need, which is pretty mucj just rate limiting
16:27:52 <mlavalle> salv-orlando: irenab said she is going to submit a spec next week
16:27:55 <irenab> I'll recehck with sc68al, but tend to go for rate limit ML2 extension and not QoS Service
16:27:57 <matrohon> salv-orlando : ^^ can you sum up the agreement you had with sean about Qos extension?
16:28:22 <salv-orlando> it’s just to resubmit his spec as it is - just scoped down to rate-limiting only.
16:28:34 <manishg_> like salv-orlando said, QoS has a lot of implications
16:28:48 <irenab> salv-orlando: if this is only rate limit, why need to go via QoS Resource?
16:28:50 <rkukura> salv-orlando: Does it extend port with a rate limit attribute?
16:28:51 <salv-orlando> looking forward to review the spec. Keep in minding SPD and SAD for neutron
16:29:17 <salv-orlando> those are questions you should ask sc68cal. He owns the current proposal.
16:29:48 <Sukhdev> irenab: can you please take this offline and submit the spec accordingly?
16:29:58 <irenab> OK, so seems we can come to the discussion once spec will be out for review next week
16:30:06 <irenab> Sukhdev: sure, thanks
16:30:12 <rkukura> I’d suggest irenab contact sc68cal and see if what she proposes is at least a start on what he needs
16:30:33 <Sukhdev> In the interest of time - lets move on to the next topic
16:30:35 <irenab> rkukura: agree
16:30:56 <Sukhdev> #topic: discuss port security
16:31:03 <Sukhdev> this is the second action item
16:31:29 <Sukhdev> I do not see the owner for this topic present here
16:31:40 <yamahata> hi
16:31:51 <Sukhdev> yamahata: hi
16:31:52 <yamahata> I think portsecurity extension
16:32:21 <yamahata> Now -2 on the spec was removed by Kyle as the related parties agreed to unite.
16:32:37 <yamahata> So we are now able to make progress.
16:32:53 <yamahata> To be precise, I haven't received any reply from Ian.
16:33:08 <rkukura> yamahata: Is this the existing portsecurity extension API, or a different one?
16:33:08 <yamahata> But other cisco developers will arbitrate with him.
16:33:12 <Sukhdev> yamahata: link, please?
16:33:22 <yamahata> https://review.openstack.org/#/c/99873/
16:33:37 <yamahata> rkukura: yes
16:33:56 <yamahata> So the tech details can be discussed there.
16:35:19 <Sukhdev> Do we want to discuss it now or shall we put it on next week's agenda? - have few critical things to cover
16:35:43 <yamahata> I'm fine with the next week.
16:36:05 <Sukhdev> Is everybody OK with that?
16:36:20 <Sukhdev> yamahata: can you put this on next week's agenda?
16:36:23 <yamahata> anyway we can continue discussion with spec review.
16:36:27 <yamahata> Sukhdev: sure
16:36:41 <Sukhdev> OK moving on
16:36:46 <rkukura> sounds good to me
16:36:55 <Sukhdev> #topic Bugs
16:37:03 <Sukhdev> Shiv is not here today
16:37:23 <Sukhdev> anybody wants to discuss any critical bug?
16:37:44 * Sukhdev waiting
16:38:01 <Sukhdev> Moving along then….
16:38:27 <Sukhdev> I am going to skip the specs section and go to the next import topic
16:38:32 <matrohon> https://review.openstack.org/#/c/116924/20
16:38:49 <Sukhdev> matrohon: you made it :-):-)
16:38:50 <matrohon> if anybody wants to review ^^
16:39:11 <matrohon> Shukdev : :)
16:39:28 <Sukhdev> matrohon: I remember discussing this in the past
16:39:49 <Sukhdev> matrohon: anything specific you have in mind?
16:40:18 <matrohon> Shukdev : it was a terirble mess :)
16:40:56 <Sukhdev> matrohon: :-)
16:41:17 <Sukhdev> I think we need this fix, right?
16:41:44 <matrohon> it's important for ML2 mech driver
16:42:18 <matrohon> whitout this they are not away of gw port removal when a router gets deleted
16:42:28 <Sukhdev> matrohon: I am bit confused - if I do delete_router() I see delete_port() on my MD
16:43:09 <rkukura> Sukhdev: Since deleting the router deletes its ports, the MDs should see this.
16:43:38 <matrohon> Shukdev : you shouldn't be aware of the the ext gw port
16:43:47 <matrohon> Shukdev : you shouldn't be aware of the ext gw port removal
16:43:50 <Sukhdev> matrohon: my bad - I was not thinking about gateway port
16:44:09 <Sukhdev> yes, agree
16:44:19 <rkukura> Why is the gateway port special?
16:44:34 <rkukura> If the gw port is deleted, MDs still need to see this
16:44:35 <Sukhdev> rkukura: good question
16:45:02 <rkukura> I think the router cannot be deleted until the “internal” networks are removed, so their ports are already gone
16:45:17 <Sukhdev> I can test this and report back, if you like
16:45:20 <matrohon> rkukura : +1
16:45:39 <matrohon> but you canb delete a router with an ext gw port on it
16:45:47 <matrohon> and it deletes the ext gw port
16:45:51 <manishg_> I had reviewed something like this.  My questions - why is gw port special, and why is there check specifically to check with vpn service only... and not a generic mechanism.
16:45:55 <rkukura> Lets keep in mind that not all deployments use the external bridge for the external network - they can use any normal provider network
16:47:11 <rkukura> I think the historic behavior is that deleting the router removes it from the external network, hence auto-deleting the gw port is required
16:47:35 <matrohon> rkukura : that's the way I understand it too
16:48:27 <matrohon> but I agree that forbiding the router deletion if any port is still attached would make more sense
16:49:59 <Sukhdev> matrohon: So, the question is - do we block router_delete() or ensure that MDs know when a GW port is auto deleted? Did I get it right?
16:50:19 <rkukura> matrohon: agree in principle, but that would be an incompatible change. I think it is important that this auto-deletion is done via the core plugin rather than directly via the DB.
16:51:03 <Sukhdev> rkukura: I seem to agree with your assertion
16:51:09 <matrohon> Shukdev : as rkukura just said, blocking the router deletion would be incompatible
16:51:39 <Sukhdev> Looks like we are almost there -
16:52:29 <Sukhdev> We can now matrohon patch to match with this understaing
16:52:39 <Sukhdev> ^review^
16:52:56 <rkukura> Sukhdev: do we want to see if the team is OK with the proposed charter?
16:53:02 <Sukhdev> Folks - we are running out of time - need to really move on
16:53:14 <Sukhdev> rkukura: yes
16:53:24 <Sukhdev> #topic: ML2 Charter for Kilo
16:53:50 <Sukhdev> Folks, Bob put our the charter for the ML2 sub-comittee for Kilo
16:54:07 <Sukhdev> #link https://etherpad.openstack.org/p/ML2_Subteam_Charter
16:54:16 <Sukhdev> Did you have a chance to review it?
16:54:41 <Sukhdev> Do we all agree with it - I reviewed it and liked it
16:54:42 <rkukura> If the team is OK with this, I’ll move it to https://wiki.openstack.org/wiki/NeutronSubteamCharters later today
16:55:11 <yamamoto> it looks reasonable to me.
16:55:23 <mlavalle> rkukura: I read it and seems very comprehensive to me
16:55:36 <irenab> rkukura: +1
16:55:38 <Sukhdev> As rkukura says, we have an action item to move it to the wiki - wanted to get everybody's agreement before doing it
16:55:39 <rcurran> looks good to me ... are you looking for names to go along w/ the md's?
16:55:53 <Sukhdev> Shall we say we all agree?
16:56:02 * Sukhdev waiting
16:56:06 <matrohon> l2 agent refactoring will be homed in another subgroup?
16:56:39 <mlavalle> matrohon: yes, rosella is writing a spec for that
16:57:26 <matrohon> mlavalle : thanks;
16:57:30 <Sukhdev> #agreed: Team agrees to the ML2 charter for KIlo as listed in https://etherpad.openstack.org/p/ML2_Subteam_Charter
16:57:40 <rkukura> mlavalle, matrohon: I’m not sure if the refactoring is the same as the modularization we have been discussing for several cycles, so we should coordinate these efforts
16:57:41 <manishg_> mlavalle: which subgroup?
16:57:50 <manishg_> Sukhdev: +1 on charter.
16:58:08 <rkukura> Please add any comments/corrections to the etherpad soon before I copy it
16:58:36 <manishg_> rkukura: at the summit l2 modular agent was discussed.  I was assuming 'refactor' was loosely implying that
16:58:44 <Sukhdev> We are almost out of time
16:58:51 <manishg_> but good to get the clarification.
16:58:59 <mlavalle> rkukura: ok, i'd be happy to help with that
16:59:00 <rkukura> manishg_: agreed
16:59:15 <Sukhdev> Please ensure to review https://review.openstack.org/#/c/134680/
16:59:50 <Sukhdev> This spec talks about the vendor code split - I wanted to spend more time on this, but, we are out of time - so, please review this spec and post your comments
17:00:15 <rkukura> there is also an email thread on that
17:00:33 <sadasu> do we have to say in the ML2 charter that we will have work to do based on what happens in that spec?
17:00:41 <Sukhdev> rkukura: correct - unfortunately, I do not have link handy
17:01:15 <rkukura> sadasu: The draft charter does refer to this
17:01:43 <Sukhdev> Time is up folks - thanks for attending
17:01:43 <sadasu> rkukura: ok...now I see it
17:01:47 <manishg_> thanks.
17:01:51 <irenab> thanks
17:01:55 <rkukura> thanks Sukhdev!
17:01:58 <Sukhdev> #endmeeting