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