14:00:03 <mlavalle> #startmeeting neutron_drivers
14:00:04 <openstack> Meeting started Fri Aug 31 14:00:03 2018 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:07 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:16 <haleyb> hi
14:00:18 <mlavalle> hi
14:00:19 <slaweq> hi
14:00:35 <mlavalle> hey slaweq, elcome to your first drivers meeting
14:00:44 <slaweq> hey :)
14:00:55 <slaweq> and welcome drivers team!
14:01:15 <mlavalle> let's wait a couple of minutes for amotoki or yamamoto
14:01:18 <manjeets_> hi
14:01:26 <mlavalle> hi manjeets_
14:02:07 <slaweq> amotoki sent email today that he will not be available
14:02:09 * njohnston spectates
14:03:14 * bcafarel joins the spectators too for slaweq's first meeting
14:03:20 <mlavalle> LOL
14:03:21 <slaweq> LOL
14:03:31 <mlavalle> ok, let's get going
14:04:07 <mlavalle> Firt one that we are going to discuss today is https://bugs.launchpad.net/neutron/+bug/1774463
14:04:08 <openstack> Launchpad bug 1774463 in neutron "RFE: Add support for IPv6 on DVR Routers for the Fast-path exit " [Wishlist,Triaged]
14:06:28 <haleyb> i don't see swami here...
14:07:57 <mlavalle> we don't need him to be here, do we?
14:08:57 <haleyb> i guess not, just thinking of what else this entails than those 2 items
14:09:21 <slaweq> I wonder what will be in case if there is IPv6 connected to instance but there is no FIP assigned
14:09:34 <slaweq> then there will be no FIP namespace on node, right?
14:09:35 <mlavalle> in principle, the idea seems sensible to me
14:10:20 <mlavalle> slaweq: yes, that would be the case
14:10:37 <haleyb> there would still be a FIP namespace, shared for IPv6 usage now as for floating
14:11:29 <slaweq> ahh, so this FIP namespace will be created even if there will be no FIP associated to port, right?
14:12:35 <haleyb> yes, and it should be able to forward IPv6, right now all IPv6 is centralized
14:13:28 <slaweq> ok
14:13:33 <mlavalle> let me point out that there is precedent as far as code: https://review.openstack.org/#/c/143917/ and https://review.openstack.org/#/c/138588/
14:13:54 <mlavalle> the comments in the patches seem favourable, but pending approval of the BP
14:14:33 <haleyb> yes, and https://review.openstack.org/#/c/143917/ had some concepts that kind-of made this possible, if i remember some hacking i did with it a few years ago
14:15:09 <mlavalle> haleyb's question in regards what else is entailed seem appropriate. could you elaborate a little bit?
14:16:17 <haleyb> mlavalle: sure.  today with FIP we to ARP proxy, i'd assume we'd also need ND proxy for this, since it doesn't mention BGP, etc
14:16:36 <mlavalle> right
14:16:44 <haleyb> i don't know whethere it was just a typo to say "ra proxy"
14:16:46 <haleyb> ?
14:17:06 <mlavalle> yeah, I see what you say
14:17:55 <mlavalle> so I propose to leave clarifying question in the RFE, for swami to respond so we can reconsider again
14:18:13 <haleyb> i'll add a comment
14:18:27 <mlavalle> you ok, slaweq?
14:18:36 <slaweq> yes
14:18:43 <slaweq> sounds good
14:18:43 <haleyb> mlavalle: and one other thing...
14:20:06 <haleyb> i guess maybe it's non-obvious to me that this requires subnet pool/address scopes to work (or maybe PD), since the ingress/egress rules drop traffic otherwise
14:20:19 <haleyb> or maybe it's obvious i need to ask :)
14:20:30 <mlavalle> it doesn't hurt to ask
14:21:08 <mlavalle> it's part of our job, ask questions, even seemingly obvious ones
14:21:10 * haleyb is only remembering since he found a scoping issue the other day
14:21:52 <slaweq> I agree. We should ask questions :)
14:23:53 <mlavalle> haleyb: are you planning to ask the questions now or after the meeting?
14:25:59 <mlavalle> slaweq: as you can see this meeting runs at a much slower pace. When I started attending it drove me crazy. But it is the way it should be. It's like the house of representatives and the Senate in US Congress. The Senate is much slower ;-)
14:26:15 <slaweq> :)
14:26:23 <slaweq> yes, I see but it's fine for me
14:26:24 <mlavalle> because we should conider things
14:26:33 <slaweq> I understand that
14:29:12 <mlavalle> ok, it seems we can move on, thanks haleyb for the comment
14:29:32 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1777627
14:29:32 <openstack> Launchpad bug 1777627 in neutron "RFE: QoS – rule's management (set,delete, show…) requires <qos-policy> parameter in addition to <rule-id>" [Wishlist,Triaged]
14:30:19 <njohnston> yamamoto's suggestion is wise
14:30:23 <slaweq> I read it yesterday and I think that yamamoto's idea is good to fix this issue
14:32:42 <mlavalle> should have it been like that since the beginning?
14:32:56 <slaweq> I think it could be like that
14:33:12 <slaweq> in fact each rule has own uuid so it's uniq
14:33:19 <mlavalle> do you remember why we went the other way?
14:33:33 <slaweq> no, I wasn't working on it then
14:33:38 <slaweq> I joined later
14:34:10 <slaweq> I can ask ajo next week, maybe he will remember something
14:34:28 <mlavalle> maybe we were a little too orthodox with our ReST design
14:34:42 <mlavalle> and the resource / sub-resource relationship
14:34:51 <njohnston> ISTR it was because we were trying to follow the pattern set in other APIs, and we did not think enough about treating rules as first class objects
14:34:57 <slaweq> that can be the reason
14:35:21 <mlavalle> yeah, that's more or lesss what I meant with my comment
14:35:56 <mlavalle> I am just trying to make sure we don't miss something obvious that they originally took into consideration
14:36:29 <slaweq> but I think that yamamoto's suggestion is good, having such aliases internally will allow us to be backward compatible and provide new URI
14:37:00 <mlavalle> yes, I think it is a sensible approach and we make life easier to the client developers
14:37:14 <slaweq> +1
14:37:15 <manjeets__> yamamoto's solution is suggestion a api change ? would that v2/qos/bandwidth_rule/id will be an alias of existing api ?
14:37:20 <mlavalle> and we even save a rountd trip
14:37:26 <mlavalle> API round trip
14:38:27 <mlavalle> manjeets__: yes, that's my understanding
14:38:46 <slaweq> manjeets__: IIUC he is proposing to add new aliases for existing API
14:39:24 * haleyb re-joins after a vpn outage
14:39:31 <mlavalle> LOL
14:39:44 <manjeets_> ah ok gotcha make sense ! if we change client that'll be two calls
14:39:54 <slaweq> manjeets_: exactly
14:40:02 <mlavalle> haleyb: we are considering https://bugs.launchpad.net/neutron/+bug/1777627
14:40:02 <openstack> Launchpad bug 1777627 in neutron "RFE: QoS – rule's management (set,delete, show…) requires <qos-policy> parameter in addition to <rule-id>" [Wishlist,Triaged]
14:40:06 <manjeets_> I'm also facing vpn outages today
14:40:17 <mlavalle> manjeets_: in your case we noticed
14:40:21 <manjeets_> have to look logs anyway after meeting
14:40:21 * njohnston got skunked by the same vpn outage as haleyb
14:40:32 <slaweq> LOL
14:40:42 <slaweq> global disaster :D
14:40:55 <mlavalle> with haleyb and njohnston I just thought they were thinking deeply
14:41:13 <haleyb> my proxy in inside redhat, so noone probably noticed
14:41:13 <mlavalle> which they usually do ;-)
14:44:16 <haleyb> i'm fine with this alias, if you're waiting for me
14:44:33 <manjeets__> ++
14:44:35 <mlavalle> haleyb: we were waiting for you
14:44:39 <njohnston> ++
14:44:51 * slaweq also had some vpn issues now :/
14:45:14 <mlavalle> the only question is whether the submitter will pitch in with the implementation. If he doesn't, I'll take it up
14:45:20 <slaweq> for me idea of this mirroring of calls and make them easier is good
14:45:33 * mlavalle writing comment in RFE
14:45:46 <slaweq> I don't think he will do it as he is workig on different things IIRC
14:47:25 <njohnston> It should be a pretty simple change
14:48:00 * njohnston wonders if the old "low-hanging-fruit" tag is used anymore for changes that are good for more junior members
14:48:19 <slaweq> njohnston++
14:48:45 <slaweq> that could be good for someone new IMO :)
14:49:02 <mlavalle> I assigned it to me already. If he wants to implement, he can change the assignment
14:49:09 <njohnston> and in the neutron world the fruit is so often placed very, very high
14:49:51 <manjeets__> fruits and cakes are lie
14:50:25 <mlavalle> slaweq, njohnston: you are making a good point. If he says he won't implement it, I will advertise it in the weekly meeting. If nobody steps up, then I'll take it
14:50:48 <slaweq> mlavalle++
14:51:07 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1785213
14:51:07 <openstack> Launchpad bug 1785213 in neutron "[RFE] Automatically allow incoming DHCP traffic for networks which uses external dhcp server" [Wishlist,Triaged] - Assigned to Slawek Kaplonski (slaweq)
14:51:35 <slaweq> yes, this one is mine :)
14:53:19 <slaweq> should I explain it?
14:53:55 <mlavalle> mhhh, it seems pretty clear to me
14:54:05 <mlavalle> maybe answer some questions
14:54:12 <slaweq> sure
14:54:34 <mlavalle> the subnets on that network, would become no-dhcp with that option?
14:54:50 <haleyb> it seems straightforward to me too, and i had the same question ^^^
14:55:18 <slaweq> no, I was thinking that this would work only if enable_dhcp would be set to false
14:55:37 <slaweq> or even differently
14:56:13 <slaweq> in fact this flag would be "equal" to configure proper security groups to allow dhcp traffic going from outside
14:56:31 <slaweq> so if that flag would be set such traffic would be allowed for all ports in network
14:56:54 <njohnston> allowed regardless of security group settings?
14:56:56 <slaweq> and ports then could accept dhcp responses from both internal and external dhcp server - depends on user
14:57:06 <slaweq> njohnston: yes
14:57:29 <slaweq> basically problem with using external dhcp server is that response from such server is blocked by default by SG
14:57:31 <mlavalle> ahhh!
14:57:46 <slaweq> it can be unblocked by adding proper SG rule
14:58:02 <slaweq> but it's not "user friendly" (at least I had such feedback)
14:58:06 <mlavalle> so just allowing the traffic from the external dhcp server, let the instance / user handle the response from external and internal
14:58:24 <slaweq> mlavalle: yes
14:58:42 <slaweq> dhcp traffic outgoing from instance is allowed always currently
14:58:45 <slaweq> it's hardcoded
14:58:56 <slaweq> but response will be blocked by default
14:59:12 <mlavalle> we won't make a decision on it because we need another vote in this case, but I would add this clarification to the RFE
14:59:16 <haleyb> do we want neutron dhcp running?  would that cause a race?  i.e. first answer wins ?
14:59:37 <slaweq> haleyb: it may
14:59:44 <haleyb> slaweq: and how would metadata work?
14:59:51 <slaweq> but this flag would be by default disabled
15:00:04 <slaweq> haleyb: metadata would not work in such case
15:00:08 <mlavalle> ok, let's continue the discussion in the RFE
15:00:21 <mlavalle> the relases guys will mad at us otherwise
15:00:26 <smcginnis> :)
15:00:26 <mlavalle> thanks for attending
15:00:30 <manjeets__> thanks :)
15:00:31 <mlavalle> #endmeeting