22:01:56 <armax> #startmeeting neutron_drivers
22:01:57 <openstack> Meeting started Thu Mar 24 22:01:56 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:01 <openstack> The meeting name has been set to 'neutron_drivers'
22:03:08 <njohnsto_> o/
22:04:19 <armax> we have a few sticky triaged RFE bugs we’re gonna have to talk about again
22:04:22 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:04:33 <armax> but we have a few new entries
22:04:34 <armax> too
22:05:10 <armax> bug 1453667
22:05:10 <openstack> bug 1453667 in neutron "[RFE] Update existing ports when changing --port_security_enabled=False in network" [Wishlist,Triaged] https://launchpad.net/bugs/1453667
22:05:17 <armax> is actually relatively old
22:05:32 <armax> and I spotted yesterday during one of my scrubs
22:06:17 <armax> this issue has actually been reported a few times already
22:06:49 <armax> people expect that flipping the security flag on the network propagates to the ports, but it currently doesn't
22:07:10 <armax> doing so has clear performance implications
22:07:37 <ihrachys_> armax: I would say, security implications are more important in this context
22:07:48 <amuller> do we currently allow updating port security on a port? does it do the right thing and notify the L2 agents?
22:07:55 <armax> ihrachys_: they would be expected though
22:08:06 <ihrachys_> armax: for performance, it may be ok (actually, for qos we do apply policy changes to all ports in a network)
22:08:07 <armax> amuller: I believe it does
22:08:14 <amuller> ok
22:08:23 <amuller> armax: what performance issue did you have in mind?
22:08:26 <armax> ihrachys_: I was going to confirm with you about this
22:09:00 <armax> you’d have to update policies on all ports in a network in one go
22:09:48 <armax> ports may be spread out over many hosts
22:09:57 <armax> the flipping may cause a storm
22:10:12 <amuller> isn't that like adding a security group rule?
22:10:13 <armax> besides the other issue is dealing with partial updates
22:10:18 <armax> amuller: yes it is
22:10:27 <armax> and that’s bad enough already :)
22:10:41 * amuller shrugs
22:11:08 <ihrachys_> I don't think we should focus discussion on performance implications but more on api consistency.
22:11:26 <ihrachys_> though for port security 'security' aspect should also be taken in account
22:11:51 <ihrachys_> I would say, if that would be a new feature we plan to implement, I would go with port updates on network attr update
22:12:05 <armax> ihrachys_: besides qos and port security do we have other examples of such properties?
22:12:21 <ihrachys_> but since we are already shipping the extension with a slightly different behaviour, it would be quite unsafe to change that
22:12:22 <armax> that apply to both parent and child resource?
22:12:39 <armax> I don’t recall on the top of my head
22:12:59 <ihrachys_> neither me
22:13:03 <armax> perhaps if the flag had been called ‘default_port_security'
22:13:22 <armax> the confusion for the user wouldn’t be so bad
22:14:39 <armax> I mean default_port_security on the network
22:14:44 <armax> and port_security on the port
22:15:51 <armax> the existing behavior would have been more easily expected
22:16:04 <armax> anyhow
22:16:11 <ihrachys_> do we really want to consider changing behaviour for the feature? however silly or inconsistent it may be, it's already there.
22:16:32 <armax> assumed that we can’t really change behavior without a new extension we’d have to mark this as wontfix I suppose?
22:16:56 * carl_baldwin just typed a message but doesn't see it in the history
22:17:12 <armax> carl_baldwin: yup, haven’t seen it
22:17:13 <ihrachys_> I guess so. maybe docs could be updated to make the behaviour more clearly defined.
22:17:21 <carl_baldwin> Is there a compelling use case for turning on/off port security for all existing ports?  (regardless of what it is called)
22:17:28 <armax> ihrachys_: yes, documentation would help manage expectations
22:17:51 <armax> carl_baldwin: I can’t think of any
22:18:05 <armax> carl_baldwin: besides the convinience
22:18:20 <ihrachys_> well, if there was no such case, network resource would not have that attr in the first place
22:18:22 <armax> but if we try to minimize the amount of orchestration we do internally
22:18:25 <carl_baldwin> But, if there is no use case, what the convenience be for?
22:19:06 <jhesketh> Morning
22:19:06 <carl_baldwin> I tend to think that this is more about managing expectations too.
22:19:16 * ihrachys_ notes that we may time box this discussion
22:19:28 <armax> ihrachys_: the attr on the network is ‘the default security policy to be applied on port creation'
22:20:02 <armax> ihrachys_: agreed….let’s mark it wontfix for now
22:20:03 <armax> moving on
22:20:06 <ihrachys_> armax: yeah, but if you set it to False, you probably mean that most (or all) ports there will not have fw
22:20:07 <carl_baldwin> ++
22:20:16 * ihrachys_ shuts
22:20:19 <armax> bug 1507499
22:20:19 <openstack> bug 1507499 in neutron "[RFE] Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
22:20:44 <dougwig> didn't we punt this one?
22:20:54 <armax> this is a catch-all of the bugs filed against improving visibility into neutron
22:21:05 <armax> dougwig: we punted it to the mid-cycle
22:22:20 <armax> as well as troubleshooting
22:22:34 <amuller> Hynek and I have a proposal for neutron diagnostics
22:22:40 <Sukhdev> .me lurks around
22:22:41 <amuller> there's lots of interesting details such as client side vs api
22:22:44 <amuller> in-tree or out of tree
22:22:44 <armax> I would initially like to tackle the visibility part
22:23:55 <armax> the proposal is too tied to agents
22:24:01 <armax> unless I misunderstood
22:24:47 <armax> I’d rather come up with a good abstract representation of any failure state in which a resource might be first
22:24:55 <armax> only to delve later into implementation detauls
22:24:56 <armax> details
22:25:21 <amuller> do we want a design session for this?
22:25:24 <amuller> at the summit?
22:25:28 <amuller> or we do we want to file a spec?
22:25:43 <armax> amuller: we could potentially have a fist fight at the summit sure
22:25:46 <armax> er, session
22:25:47 <amuller> heh
22:26:02 <armax> we can only punt this topic so many times :)
22:26:51 <amuller> well, Newton just opened
22:27:03 <amuller> do you want to punt it to O? =D
22:27:07 <armax> Z
22:27:18 <amuller> who cares why networking doesn't work, right?
22:27:23 * carl_baldwin notes that is just punting it once
22:27:56 <amuller> New features are cool, but I think we should be focused on making neutron more usable
22:28:07 <armax> before having this discussed at the summit though I’d like to get to a degree on consensus amongst ourselves
22:28:52 <Sukhdev> Perhaps you want to break the problem into smaller pieces so that we can implement in a phases
22:28:58 <armax> as of now no-one seems to agree or disagree with me
22:29:22 <armax> Sukhdev: that’s what I am trying to do by suggesting to focus on the modeling of the visibility part
22:29:41 <Sukhdev> In that case, we are in agreement -
22:30:17 <armax> ok, let me refresh the content of the bug report and we’ll talk again next time, I guess
22:30:32 <armax> bug 1527671
22:30:32 <openstack> bug 1527671 in neutron "[RFE]Neutron QoS Priority Queuing rule" [Wishlist,Triaged] https://launchpad.net/bugs/1527671
22:31:03 <armax> from latest notes by ajo I gather this will be deferred until we solidying the current dscp approach
22:31:12 <armax> ihrachys: am I off here?
22:31:36 <ihrachys> armax: haven't we just solidified dscp by landing it in N?
22:32:27 <ihrachys> that said, classifier is mentioned there. I may miss something on that one.
22:32:28 <armax> ihrachys: it has just landed, do you think it’s already rock solid?
22:32:37 <armax> ihrachys: if so, I am impressed
22:32:47 <ihrachys> armax: of course! everything we land is rock solid right? :)
22:32:56 <armax> riiight
22:32:56 <ihrachys> unless it's not
22:33:07 <armax> silly me
22:33:49 <ihrachys> I don't see how the RFE is BOUND to classifier
22:33:53 <armax> that said, the submitted promised to get back to the rfe but he didn’t
22:34:05 <armax> so let’s give him a chance to revisit its proosal
22:34:09 <ihrachys> but maybe it's a matter of priorities, and ajo wants the team to step back and see about foundation
22:34:10 <armax> proposal
22:34:11 <ihrachys> *think
22:34:44 <armax> ihrachys: do you guys have a general plan for N?
22:34:54 <armax> ihrachys: as far as QoS is concerned?
22:35:03 <ihrachys> I would probably ask qos team to provide reasoning behind pushing back the proposal until classifier thing is implemented. if it's priorities set by the group, it's ok.
22:35:33 <ihrachys> armax: I am 'merely' helping ajo, I don't set strategy for the team
22:36:23 <armax> ihrachys: ok
22:36:32 <armax> bug 1540512
22:36:32 <openstack> bug 1540512 in neutron "[RFE] Host Aware IPAM" [Wishlist,Triaged] https://launchpad.net/bugs/1540512
22:36:50 <armax> carl_baldwin: I am assuming you’d need this in some form or another
22:37:29 <carl_baldwin> I need to review the comments since I last looked at this.
22:37:57 <carl_baldwin> I need to relate it to segment-aware IPAM which we're already working on as part of routed networks.
22:38:45 <carl_baldwin> #action carl_baldwin will review https://launchpad.net/bugs/1540512
22:38:45 <openstack> Launchpad bug 1540512 in neutron "[RFE] Host Aware IPAM" [Wishlist,Triaged]
22:38:50 <carl_baldwin> That's about all I can do this week.
22:38:51 <armax> carl_baldwin: do you think it’s justified to track this with a separatte bug?
22:39:10 <armax> carl_baldwin: tomorrow is FridaY!
22:39:21 <carl_baldwin> armax: yes, I think so.
22:39:27 <armax> :)
22:39:35 <carl_baldwin> But, it isn't isn't holding up routed networks.
22:39:49 <armax> carl_baldwin: agreed
22:41:19 <armax> carl_baldwin: I only wonder if the two can be orthogonal and thus handled separately
22:41:46 <armax> in which case this may have its merits to proceed on its own
22:42:03 <carl_baldwin> armax: Could be.  I'll look for that.
22:42:34 <armax> carl_baldwin: that said I am not sure how much implementation can follow, but that’s a different matter
22:42:39 <armax> let’s move on
22:42:42 <carl_baldwin> ok
22:42:50 <armax> bug 1544676
22:42:50 <openstack> bug 1544676 in neutron "[RFE] Support for multiple L2 agents on a host" [Wishlist,Triaged] https://launchpad.net/bugs/1544676 - Assigned to Narender (narender-soorineeda)
22:43:30 <armax> my opinion on this hasn’t changed
22:43:48 <ihrachys> hm. can't we already run sriov + ovs on the same node?
22:44:51 <armax> ihrachys: yes, but this is slightly different
22:46:04 <armax> unless I hear an uproar I am gonna kill this
22:46:19 <armax> moving on
22:46:22 <armax> bug 1544768
22:46:22 <openstack> bug 1544768 in neutron "[RFE] Differentiate between service and floating subnets" [Wishlist,Triaged] https://launchpad.net/bugs/1544768 - Assigned to Brian Haley (brian-haley)
22:46:22 <ihrachys> thumb down
22:46:46 <armax> ihrachys: thumb down as you agree or disagree with me?
22:46:54 <amuller_> armax: I agree with killing it
22:47:00 <ihrachys> armax: agreed with killing
22:47:06 <armax> oh, I was hoping in a fist fight
22:47:07 <armax> too bad
22:47:09 * ihrachys feels violent
22:47:12 <armax> anyhoo
22:47:39 <carl_baldwin> armax: I see you ask for a spec.
22:47:58 <carl_baldwin> armax: I'll ping haleyb about doing this.
22:48:19 <armax> carl_baldwin: I think that would help getting more eyes on it
22:49:00 <carl_baldwin> aye aye
22:49:02 <armax> carl_baldwin: the objective is clear to me and I agree that it would be desirable to be able to distinguish between the various ip spaces associated to an external network
22:49:15 <armax> we’d have to agree on the naming and meaning
22:49:20 <armax> that’s why the spec is useful
22:49:31 <armax> so I am OK with this, if we have quorum
22:49:32 <amuller_> carl_baldwin: is this relevant for non-DVR routers?
22:49:38 <armax> ihrachys, amuller_ fist fight?
22:49:49 <carl_baldwin> amuller_: Not at first.
22:49:52 <armax> dougwig, Sukhdev anyone else?
22:49:53 <armax> oh
22:49:55 * armax sad
22:50:05 <carl_baldwin> amuller_: Well, ya, it is.
22:50:17 <amuller_> carl_baldwin: ok, for DVR, would this be useful without routed networks or address scopes?
22:50:22 <carl_baldwin> It will allow any router to use a private IP as its gateway IP.
22:50:26 <amuller_> I'm trying to understand if this RFE is useful on its own or does it have dependencies
22:50:39 <carl_baldwin> amuller_: Yes, it will be useful without anything else.
22:50:52 <armax> amuller_: you’d need the l3 agent to use it
22:50:55 <amuller_> carl_baldwin: this would essentially disable SNAT or what am I missing?
22:51:04 <amuller_> (using a private IP on the 'qg' device)
22:51:09 <armax> carl_baldwin, amuller_ it won’t be useful on its own
22:51:17 <carl_baldwin> amuller_: It essentially uses private IPs for routers where public IPs are not needed.
22:51:23 <carl_baldwin> armax: why?
22:51:32 <armax> I mean I see two pieces of work
22:51:46 <armax> one which is to model the service subnets
22:51:58 <amuller_> armax: let's assume we implement both the server and agent part for this RFE
22:51:59 <armax> the other is using them to change the l3 logic
22:52:26 <amuller_> carl_baldwin: if I use a private IP on my router's external device, can it still do SNAT somehow?
22:52:28 <armax> amuller_: right, then I see no other depedency
22:52:28 <carl_baldwin> I thought they went together.  Which one are we talking about then?  Just the modeling?
22:52:55 <carl_baldwin> amuller_: Several operators have requested doing this so they can use another NAT device.
22:53:28 <armax> carl_baldwin: the bug description seems to focus on the modeling only
22:53:41 <armax> carl_baldwin: but I understand that you’d want to use it too
22:53:51 <amuller_> carl_baldwin: so the neutron router would route to its own gateway (without SNAT or any form of NAT, unless the source IP has a floating IP attached), then that gateway would be configured to NAT?
22:53:56 <amuller_> carl_baldwin: isn't that what the enable_snat flag does?
22:53:57 <carl_baldwin> armax: I figured you would but we can elaborate.
22:53:58 <armax> and change the existing allocation policy for dvr gateway ports
22:54:21 <carl_baldwin> amuller_: no.  The Neutron router still has to NAT.
22:54:31 <carl_baldwin> Well, may have to NAT.
22:54:51 <amuller_> I need a diagram or something
22:55:02 <amuller_> or a whiteboard :)
22:55:03 <carl_baldwin> In general, though, it would have to NAT.  Because how could the operator know what addresses the tenant is using on the private network?
22:55:09 <armax> amuller_: or a spec!
22:55:34 <amuller_> I guess so
22:55:45 <carl_baldwin> amuller_: How about this.  We write spec.  ;)
22:55:45 <armax> if we agree that this has legs then let’s approve it and we’ll get the discussion on the spec
22:55:57 <armax> 5 more minutes and I have back to back meetings :)
22:56:01 <carl_baldwin> +
22:56:03 <carl_baldwin> ++
22:56:05 <armax> bug 1560003
22:56:05 <openstack> bug 1560003 in neutron "[RFE] Creating a new stadium project for BGP Dynamic Routing effort" [Wishlist,Triaged] https://launchpad.net/bugs/1560003
22:56:25 <armax> technically speaking I am not sure why we’d need an RFE for this
22:56:29 <ihrachys> I doubt anyone is in disagreement with ^
22:56:35 <ihrachys> and yes, why RFE
22:56:38 <armax> ihrachys: right
22:56:41 <amuller_> carl_baldwin: do you want to punt BGP out?
22:56:44 <carl_baldwin> armax: I actually wondered that same thing when I moved it to Triaged.
22:56:49 <ihrachys> on relevant note, should we spin off others? like qos? :)
22:56:57 <carl_baldwin> amuller_: More like BGP may want to be punted out.
22:57:06 <armax> let’s punt all the things out
22:57:10 <amuller_> carl_baldwin: they're unhappy with review velocity or what's the deal?
22:57:30 <armax> I only wonder whether we should have a huge bikeshed session on the name of the repo
22:57:31 * carl_baldwin shrugs
22:57:52 <amuller_> I'm just interested in their reasoning
22:57:56 <armax> amuller_: it’s more elaborated than that…there’s lots of history on this, I can fill you in
22:58:01 <amuller_> armax: alright
22:58:17 <armax> that said, we’d need to chose a cunning name for the repo
22:58:39 <ihrachys> finally something to fight for
22:58:40 <armax> though I agree in limiting the scope
22:58:52 <armax> neutron-bgp may be too limiting
22:58:58 <ihrachys> and boring
22:59:09 <armax> pick your brushes and paint bug 1560003
22:59:09 <openstack> bug 1560003 in neutron "[RFE] Creating a new stadium project for BGP Dynamic Routing effort" [Wishlist,Triaged] https://launchpad.net/bugs/1560003
22:59:33 <armax> but ultimately the agreement is that we’d spin out the current BGP code we have in the neutron tree
22:59:58 <armax> and maybe more
23:00:03 <armax> #endmeeeting
23:00:15 <ihrachys> armax: typo
23:00:21 <armax> #endmeeting