15:00:29 <armax> #startmeeting neutron_drivers
15:00:29 <armax> ihrachys: no
15:00:30 <kevinbenton> o\ \o o/ \o
15:00:34 <openstack> Meeting started Tue Jan 12 15:00:29 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <openstack> The meeting name has been set to 'neutron_drivers'
15:00:41 <kevinbenton> #agreed
15:00:42 * regXboi finds a seat in the back and starts snoring quietly
15:00:43 <dougwig> we should spend 58 minutes on meeting times.
15:01:00 <mestery> \m/  (  -_-   )  \m/
15:01:12 <mestery> dougwig: One can dream
15:01:32 <armax> mestery: I was dreaming only a few minutes ago
15:01:33 <regXboi> mestery: I want to see the ascii art for "rock concert movement #1"
15:01:42 <mestery> lol
15:01:42 <njohnston> o/
15:02:04 <armax> let’s go over the list of triaged bugs
15:02:06 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe&orderby=datecreated&start=0
15:02:13 <armax> in order they have been submitted
15:02:24 <carl_baldwin> Hi
15:02:55 <armax> bug #1370033
15:02:56 <openstack> bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Wishlist,Triaged] https://launchpad.net/bugs/1370033 - Assigned to Hong Hui Xiao (xiaohhui)
15:03:15 <armax> this was approved and then shot down
15:03:25 <armax> carl_baldwin reinstated it
15:03:50 <armax> but amuller is not in the room
15:03:53 <carl_baldwin> armax: I almost marked as won't fix but I thought I'd bring it up today.
15:04:22 <kevinbenton> why did it get shot down?
15:04:24 <armax> any strong reason why we’d keep looking at this one?
15:05:00 <carl_baldwin> I don't think a strong use case for manually intervening has been made yet.
15:05:05 <armax> kevinbenton: amuller (reporter) realized that wasn’t a strong use case
15:05:22 <armax> and the admin pain could be dealt with differently
15:05:48 <kevinbenton> ok, i'll defer to carl_baldwin on this then
15:05:52 <armax> as to what was proposed in the spec
15:06:26 <carl_baldwin> But, I've heard the request from customers.  I've asked to push back on that request to see if there is really a strong use case.
15:06:39 <amuller> I need a calendar reminder for this meeting
15:07:08 <ajo> amuller : http://eavesdrop.openstack.org/calendars/neutron-drivers-meeting.ics
15:07:08 <ajo> :-)
15:07:40 <carl_baldwin> So, I'm thinking of marking won't fix for the time being.  What do you think?
15:07:42 <armax> carl_baldwin: as far as I understand this is a typical example of something that could be scripted
15:08:00 <armax> on top of existing API’s?
15:08:33 <carl_baldwin> armax: I don't think there is an API to set it.  Isn't that what it asks for?
15:08:46 <ajo> I think it's not scriptable, but I also agree there's probably no strong use case
15:08:52 <ajo> (hi btw) :)
15:08:59 <amuller> you can kinda use the admin-level add/remove routers to do this
15:09:16 <carl_baldwin> amuller: good point
15:09:22 <amuller> also from reading the spec I think we'll need to enable preempt in keepalived.conf in order for the priority field to be used
15:09:26 <amuller> which is something I don't want to do
15:09:40 <dougwig> manually picking is something that is abnormal in HA, but kind of an expected primitive.
15:10:22 <ajo> I guess it can be used to balance traffic across network nodes
15:10:32 <mestery> dougwig: ++
15:10:37 <mestery> dougwig: But don't let common sense get in the way :)
15:11:05 <amuller> it it's current iteration the spec doesn't mention an API change btw
15:11:20 <amuller> it's just a scheduler change, but the way to enforce it on the keepalived level is problematic
15:11:38 <armax> amuller, carl_baldwin: I think the use case is reasonable but how it’s tackled doesn’t let us see the end in sight
15:11:55 <armax> anyhow we should continue the discussion offline
15:12:05 <armax> it looks like we still have no consensus on this one
15:12:05 <kevinbenton> tag it as low-hanging-fruit for new contributors :)
15:12:12 <armax> kevinbenton: bad idea
15:12:18 <armax> this is not a trivial fix
15:12:29 <kevinbenton> mid-hanging-fruit?
15:12:29 <armax> #bug 1505631
15:12:30 <openstack> bug 1505631 in neutron "QoS VLAN 802.1p Support" [Wishlist,Triaged] https://launchpad.net/bugs/1505631
15:12:33 <armax> bug #1505631
15:13:01 <ihrachys> armax: not sure what you meant by saying qos is limited to hypervisor
15:13:25 <armax> ihrachys: if I understand the proposal of the submitter correctly
15:13:34 <armax> ihrachys: he’s suggesting to control QoS at the switch
15:13:48 <armax> not the vswitch on the hypervisor
15:14:09 <ihrachys> really?..
15:14:22 <ihrachys> where is that? Is that what 'ECN' abbreviation means?
15:14:27 <armax> but I might be wrong
15:14:28 * ihrachys sees it the first time
15:14:35 <ajo> he's suggesting to mark packets with an specific vlan 802.1p priority
15:15:01 <ihrachys> my understanding is proposal is about tagging frames; then tags may be used by external switches
15:15:33 <ajo> it's the same thing as dscp, just different technology.
15:15:34 <neiljerram> ECN is Explicit Congestion Notification, I believe
15:15:34 <armax> ajo: where do we stand on the dscp implementation?
15:15:34 <amuller> super similar to dscp no? just at the ethernet level instead of ip
15:15:41 <ihrachys> it's just another mechanism for the same thing
15:15:50 <dougwig> when are vlans created that you'd want to specify priority, inside neutron?  differing priorities for tenant vlans?  provider vlans are created outside neutron.
15:16:17 <neiljerram> #link https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
15:16:24 <ajo> armax , njohnston can probably update better about DSCP, I need to sync with them, but I believe it was on good fit
15:16:50 <ihrachys> armax: it has chances for M, but it has several missing pieces
15:16:56 <ihrachys> armax: like upgrade for rpc callbacks or l2 agent extension thing
15:17:02 <ihrachys> but I think we track it all
15:17:19 <ajo> about dependencies, correct
15:17:59 <ajo> dougwig , I think he means tagging the traffic that goes to the switches
15:18:02 <armax> I suppose that this proposal could complements DSCP
15:18:03 <njohnston> Yes, the dscp code is coming along well I think, but those prerequisites are concerns for getting it into M.  The DSCP change is concerned with bits 2-7 of the DiffServ field in the IP header; this change proposes to maange bits 0 and 1 as well.
15:18:25 <armax> at the l2 level
15:18:35 <ajo> armax : right
15:18:37 <dougwig> ajo: for tenant networks?  can't the switch auto-tag all of that?  for providers?  wouldn't you set that up in ovs manually at network creation time?  where is the use case?
15:18:48 <armax> but from an API perspective it’s too tightly coupled to the underlying l2 isolation technology
15:18:56 <armax> of choice
15:19:01 <armax> so I am not sure it’s a good fit
15:19:13 <dougwig> kevinbenton told me to say "timebox".
15:19:32 <ajo> armax : correct, we may analyze that, probably it's better to postpone VLAN 802.1p to be evaluated for N
15:19:51 <njohnston> I think it's reasonable to ask for a solid use case for why this is important to do.
15:19:58 <armax> well, I wonder if we should shoot it down entirely…but I’ll continue the discussion on the bug report
15:20:02 <ajo> because it introduces a dependency from the policy to the type of tenant isolation (or extenral network type)
15:20:10 <ajo> armax : ack
15:20:15 <armax> bug #1507499
15:20:16 <openstack> bug 1507499 in neutron "Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
15:20:17 <ihrachys> valid concern
15:20:17 <ajo> njohnston ++
15:20:37 <armax> which duplicates somewhat bug 1519537
15:20:40 <openstack> bug 1507499 in neutron "duplicate for #1519537 Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
15:21:11 <regXboi> wait
15:21:24 <ihrachys> for that one, I know a new guy in Red Hat team works on something similar and should come up with exact plan for neutron-debug in next days.
15:21:33 <regXboi> did I just read a request for a use case for why its a good idea to support an IEEE standard?!?!?!
15:22:01 <kevinbenton> regXboi: 802.11 is an IEEE standard, but we aren't defined SSID APIs yet :)
15:22:07 <dougwig> regXboi: yes, because in the neutron api context, i'm not sure it makes sense just to tick a checkbox.
15:22:25 * regXboi remains stunned into near insensibility
15:22:39 <armax> ihrachys: are you saying that a new RFE is going to be submitted?
15:22:40 <kevinbenton> i'm not sure why something that logs into VMs to run pings should live in Neutron
15:22:42 <dougwig> regXboi: if it's so obvious, it should be dead easy to do, right?
15:22:51 <ihrachys> armax: I guess you suggest not to ;)
15:23:04 <ihrachys> armax: I will communicate the bug number to the guy :)
15:23:20 <kevinbenton> couldn't troubleshooting live in a separate project or at least a completely separate service plugin?
15:23:22 <regXboi> kevinbenton: ++ on the VMs running pings living in Neutron comment
15:23:37 <armax> ihrachys: no I think here we should discuss whether creating a set of tools to troubleshoot connectivity issues belong to NEutron first
15:23:38 <ihrachys> kevinbenton: should be decoupled, yes.
15:23:45 <armax> and then how we go about it :)
15:24:09 <kevinbenton> makes sense, i can see making some internal APIs to help inspect state that a troubleshooting service plugin could call
15:24:34 <ihrachys> armax: well, there is a lot of knowledge here internalized by neutron, and there is an established orchestration bus
15:24:48 <amuller> There's an argument to be made to having a neutron-maintained troubleshooting tool
15:24:58 <amuller> shows we're serious as a community to make Neutron more usable
15:25:17 <amuller> I don't know about going in to VMs, but that's another manner :)
15:25:27 <kevinbenton> that's fine, but it doesn't need to be in neutron
15:25:43 <dougwig> 1 minute remaining on the timebox for this one.
15:25:56 <ihrachys> kevinbenton: neither neutron-debug
15:26:02 <armax> I think we need to scope this one better to judge whether it can be part of neutron or not
15:26:02 <mestery> We're going to put things into tenant VMs? Are we nuts?
15:26:11 <mestery> Who in their right mind would allow that?
15:26:13 <mestery> What tenant I mean?
15:26:18 <ihrachys> personally, I would be ok having it a separate but blessed subproject
15:26:26 <regXboi> mestery: we shouldn't do that
15:26:39 <armax> ihrachys: where it lives is not so much important if we don’t agree where we draw the line
15:26:40 <regXboi> but, we should be able to do the equiv of telecom fault isolation
15:26:50 <ihrachys> mestery: not VMs. we will tinker with switch
15:26:51 <amuller> Can we present specifics before we decide where it should live?
15:27:05 <amuller> otherwise how can you decide if it's in the scope of neutron or not?
15:27:10 <kevinbenton> this blueprint mentions running ping in VMs
15:27:20 <ihrachys> bad, bad blueprint
15:27:20 <mestery> amuller: ++, not sure why this needs to be in neutron at all
15:27:42 <ihrachys> let's postpone that one, there are no details and no agreement here
15:27:46 <amuller> kevinbenton: we had something very different in mind
15:27:58 <armax> ok it’s clear that the existing proposal may not be ideal but we’re still interested in augumenting our ability to troubleshoot connectivity issues
15:28:24 <kevinbenton> amuller: file a blueprint describing your plan
15:28:28 <armax> ihrachys: we might even shoot it down in the existing form, asking the submitter or whomever interested to come up with a different proposal
15:28:29 <kevinbenton> amuller: because it sounds different from this one
15:28:38 <amuller> kevinbenton: we're still working out the details but we will
15:28:44 <kevinbenton> amuller: s/blueprint/rfe
15:28:50 <ihrachys> armax: as you wish, I don't mind killing old artifacts
15:29:06 <ihrachys> not that the idea would be lost if it's killed
15:29:09 <armax> ihrachys: it keeps things tidy
15:29:13 <regXboi> armax: I will point out that bug 1519537 is a bit more specific about the troubleshooting items it is looking for, so it may not be a dup
15:29:14 <openstack> bug 1507499 in neutron "duplicate for #1519537 Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
15:29:14 <armax> next bug
15:29:24 <armax> bug #1507846
15:29:26 <openstack> bug 1507846 in neutron "Filtering ICMP packet based on ICMP code" [Wishlist,Triaged] https://launchpad.net/bugs/1507846
15:29:43 <armax> is sc68cal around?
15:29:50 <ihrachys> security group API extension? I am sure sc68cal will love it
15:30:07 <kevinbenton> i thought the port field with icmp already allows exactly this?
15:30:07 <armax> ihrachys: not quite a security group api extension
15:30:26 <ihrachys> oh fwaas? ok.
15:31:42 <armax> sounds like no-one feels strongly about this one
15:31:57 <regXboi> armax: I thought the last message put it back in the camp of the filer?
15:31:58 <kevinbenton> i think it needs more triage
15:32:13 <armax> ok
15:32:20 <kevinbenton> our iptables firewall internal API can certainly do this if i understand it
15:32:32 <kevinbenton> and i think it's exposed via security groups as ports on ICMP rules
15:32:54 <armax> kevinbenton: ok, that’s good feedback
15:33:26 <armax> kevinbenton: not 100% sure that’s what the user is asking but we can provide this back on the bug report
15:33:28 <armax> bug #1508155
15:33:29 <openstack> bug 1508155 in neutron "NFTables Firewall Driver" [Wishlist,Triaged] https://launchpad.net/bugs/1508155
15:34:02 * sc68cal looks
15:35:09 <armax> anyone feels strongly against an NFTable based firewall driver for linuxbridge?
15:35:31 <ihrachys> let them do it
15:35:50 <ajo> no feel against it (for linuxbridge)
15:36:15 <armax> I assume we’ll keep the strategy for ovs firewalling unchanged
15:36:24 <sc68cal> hang on, why are they trying to sell nftables as a way to do floating IPs for ipv6
15:36:39 <ihrachys> yeah, for ovs it's a different story (there are already two new drivers proposed in gerrit)
15:36:47 <kevinbenton> sc68cal: they said it's possible, not the reason for the switch though
15:37:00 <armax> sc68cal: the guy was just making conversation ;)
15:37:13 <armax> sc68cal: don’t read too much into it
15:37:20 <armax> at least that’s how I interpreted it
15:37:42 <kevinbenton> ihrachys, ajo: if it's a firewall driver, there wouldn't be anything stopping people from using it with OVS i don't think
15:37:43 <sc68cal> I mean if someone wants to write it - my concern is just having CI to test it
15:37:44 <regXboi> so we are talking (in theory) about conntrack for ovs and nftables for LB?
15:37:56 <armax> regXboi: that’s the idea, yes
15:38:02 * regXboi thinks about that
15:38:22 <ajo> kevinbenton : I think supporting the whole matrix could be a mess
15:38:25 <kevinbenton> also, the OVS support for conntrack is still dependent on specific OVS versions and kernel drivers
15:38:33 <ihrachys> kevinbenton: I mean, yeah. just that there is some OTHER use case for that driver (if that would be just ovs, we could probably say it's better to have e.g. just flows based)
15:38:36 <armax> the question is: do we want a more performant firwall driver for linuxbridge?
15:38:40 <armax> the answer is yes
15:38:46 <armax> and that can’t be the ovsfirewall
15:38:50 <armax> so it’s gotta be something else
15:39:06 <kevinbenton> ajo: so nftables is worse than iptables in the hybrid ovs bridge?
15:39:20 <kevinbenton> (not kernel drivers, kernel code)
15:39:28 <ajo> kevinbenton : we could try when they implement it, I haven't tried it
15:39:37 <regXboi> I think ihrachys may have nailed it then: let them do it
15:39:50 <armax> ajo: you’re assuming we have already candidates willing to implement this?
15:39:54 <kevinbenton> if we went this way, i would advocate for this to replace our iptables stuff completely
15:39:54 <armax> how optmistic!
15:40:18 <ajo> kevinbenton : but I'd assume, new drivers = new bugs => more things to support.
15:40:23 <sc68cal> ^ +1
15:40:31 <kevinbenton> so no new OVS firewall driver then!
15:40:34 <kevinbenton> :)
15:40:42 <ajo> kevinbenton : fair point
15:40:52 <ajo> iptables forever
15:40:53 <armax> kevinbenton: eventually iptables stuff will be superseded by nftable on linuxbridge and ovsfirewall on ovs
15:40:53 <ajo> :-)
15:41:09 <armax> if they both prove to be more performance and simpler to deploy
15:41:13 <ajo> yes, once they prove stable, that seems like a reasonable thing to do
15:41:18 <armax> but
15:41:31 <ajo> (there's always a but.)
15:41:39 <armax> there might be a chance we would end up keeping the iptables drivers for a very long time
15:41:42 <armax> anyhoo
15:41:50 <armax> that’s beyond this discussion
15:41:59 <kevinbenton> i'd say let them start doing it
15:42:05 <kevinbenton> i will review their code
15:42:05 <armax> ok, it seems we now would need to find a volunteer
15:42:10 <regXboi> does this make sense as a feature branch then so that we can do performance comparisons at the end?
15:42:28 <armax> bug #1508243
15:42:29 <openstack> bug 1508243 in neutron "Store Private Key Passphrase in Neutron-LBaaS for TLS Terminations" [Wishlist,Triaged] https://launchpad.net/bugs/1508243
15:42:30 <kevinbenton> regXboi: no need, it would just be separate driver not replacing anything
15:42:31 <ajo> I agree with kevinbenton, I don't mind reviewing it a bit too (curious about how nftables works)
15:42:34 <armax> dougwig: a reminder for you
15:42:38 <regXboi> kevinbenton: thx
15:42:42 <ihrachys> feature branches are heavy, let's not
15:43:05 <dougwig> we're going to argue this one here at the midcycle shortly. most people think its not worth it.
15:43:07 <armax> dougwig: you told us you were going to figure out what to do with this one at the mid-cycle
15:43:13 <armax> ok
15:43:30 <ajo> this is probably a single patch and pluggable  (firewall driver interface) regXboi , so let's avoid feature branches, that's heavy
15:43:31 <dougwig> we literally got started 5 minutes ago.  gimme a few.  :)
15:43:45 <armax> dougwig: I won’t shoot it down right now
15:43:46 <armax> :)
15:43:48 <armax> bug #1509046
15:43:49 <openstack> bug 1509046 in neutron "Refactoring of L3 Scheduler" [Wishlist,Triaged] https://launchpad.net/bugs/1509046 - Assigned to Aman Kumar (amank)
15:44:36 <kevinbenton> i don't see a reason not to try to unify the schedulers a bit
15:44:39 <armax> personally I am not sure if code refactoring fall in the RFE category
15:45:16 <armax> I guess this is a matter of: can we support the submitter in the code review that would clean this stuff up?
15:45:20 <kevinbenton> yeah, i could see wanting load based scheduling being an RFE
15:45:22 <armax> I’d say the answer should be yes
15:45:37 <carl_baldwin> I can review
15:45:39 <armax> kevinbenton: we have that already
15:45:48 <armax> kevinbenton: this bug doesn’t affect that
15:46:03 <kevinbenton> ok, then i agree this doesn't really need to be tracked as an RFE
15:46:04 <armax> ok, based on amotoki’s feedback, let’s see what the code looks like
15:46:38 <armax> bug #1516156
15:46:39 <openstack> bug 1516156 in neutron "IPAM migration from non-pluggable to pluggable" [Wishlist,Triaged] https://launchpad.net/bugs/1516156
15:47:21 <ihrachys> no-brainer?
15:47:34 <armax> ihrachys: yeah, but I suppose this would need a spec?
15:47:51 <ihrachys> would it be a copy of comment #6?
15:48:04 <armax> I’d hope it’d be a little more elaborated than that
15:48:05 <armax> but sure
15:48:27 <armax> we can get on with this
15:48:45 <carl_baldwin> ++
15:48:59 <armax> bug #1521194
15:49:00 <openstack> bug 1521194 in neutron "Qos Aggregated Bandwidth Rate Limiting" [Wishlist,Triaged] https://launchpad.net/bugs/1521194
15:49:28 <armax> this one is still unclear to me
15:49:50 <ihrachys> that one, I am really confused. There was a spec with a proposal that seems to me too naive; and there is no explanation how to implement anything other than naive approach.
15:50:03 <armax> it sounds to me that this wouldn’t have been submitted if we had stuff documented properly
15:50:22 <ajo> The current behaviour was documented clearly and discussed in the community
15:50:26 <ajo> it could be missleading, but it's documented
15:50:36 <ajo> not sure why we want to change it now.
15:50:38 <ihrachys> armax: I still wait for someone to show where it's documented badly
15:51:03 <armax> ajo: can you provide me with a pointer?
15:51:04 <ajo> I agree with ihrachys , such a thing could be implemented as a separate rule, when we're ready to do that
15:51:09 <armax> ajo: we can then put in the bug report
15:51:09 <ajo> armax , sure, sec
15:51:23 <armax> and perhaps be done with this
15:51:24 <ajo> I think it's both in the devref and networking guide
15:51:36 <ihrachys> ajo: ... and for a separate rule, that would require huge (!) pile of code
15:51:40 <armax> ajo: perhaps is not super cler
15:51:42 <armax> clear
15:52:10 <ajo> http://docs.openstack.org/liberty/networking-guide/adv_config_qos.html
15:52:18 <ajo> "You can attach networks to a QoS policy. The meaning of this is that any compute port connected to the network will use the network policy by default unless the port has a specific policy attached to it. Network owned ports like dhcp and router ports are excluded from network policy application."
15:52:55 <ihrachys> ajo: should we add an explicit note that it's NOT the aggregated limit?
15:53:01 <armax> ajo: this doesn’t mention anything on how the problem the author states though
15:53:26 <ajo> may be ihrachys is right, and we should add a note about that specific
15:53:33 <ihrachys> armax: it's a separate feature, there is nothing wrong about how current one is implemented or documented
15:53:45 <armax> ihrachys: I am not saying it’s wrong
15:53:57 <armax> ihrachys: but the existing documentation is ambiguous
15:53:57 <ihrachys> armax: now, the general idea of the RFE is great. I just don't see how we implement it in any meaningful way.
15:54:34 <ajo> ihrachys : it could be implemented, but I'm not sure the use cases will pay for the development time of something like that.
15:54:37 <ihrachys> armax: I can't see it. Do you have a better wording?
15:54:54 <armax> ihrachys: not on the top of my head
15:55:20 <ihrachys> armax: ok, how about posting the link and asking the reporter to provide a better wording?
15:55:36 <armax> for this one, let’s figure out if the author still wants to pursue the per-port bw limit after we better specified how QoS policies are applied
15:55:47 <armax> fair?
15:56:32 <ajo> sounds reasonable.
15:56:35 <ihrachys> armax: there is per port limit
15:56:50 <ihrachys> armax: just not aggregated from network
15:56:54 <ajo> I assumed armax meaned per-network (aggregated)
15:57:10 <ihrachys> but yeah, generally let's give the reporter a chance to show it's really useful to spin on it further
15:57:40 <armax> ihrachys: yeah..I am still sleepy
15:57:46 <armax> ok last one
15:57:47 <armax> for today
15:57:48 <armax> bug #1521783
15:57:49 <openstack> bug 1521783 in neutron "RfE: Cascading delete for LBaaS Objects" [Wishlist,Triaged] https://launchpad.net/bugs/1521783
15:58:00 <armax> dougwig: ^
15:58:19 <armax> I am personally starting to loathe these orchestration calls
15:58:37 <armax> when we have native api’s that can be used in order to achieve the same task
15:59:02 <dougwig> not high priority. the use case is simpler UIs.
15:59:05 <ihrachys> I am with armax here
15:59:22 <armax> ok
15:59:28 <armax> killed
15:59:48 <armax> I’ll capture the outcome of this meeting on the discussed bug reports
15:59:51 <armax> thanks for joining
15:59:57 <armax> have a good day/evening!
15:59:59 <armax> #endmeeting