14:00:07 <mlavalle> #startmeeting neutron_drivers
14:00:08 <openstack> Meeting started Fri May 11 14:00:07 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:28 <mlavalle> Hi there!
14:04:24 * haleyb shows up late
14:04:49 <mlavalle> hey haleyb
14:05:06 <haleyb> hey, my bot was connected but not me
14:05:19 <mlavalle> waiting on amotoki and yamamoto
14:06:19 <mlavalle> yesterday I reviewed the hjensas patches
14:06:25 <mlavalle> has some feedback
14:06:41 <mlavalle> but as soon as he responds I will review again
14:07:11 <haleyb> ack, i think he is out until next week
14:08:02 <mlavalle> they look good. my feedback was for minor things
14:15:31 <amotoki> sorry for late. I just got home.
14:15:43 <mlavalle> hi amotoki
14:15:55 <mlavalle> I was just about to close the meeting :-)
14:16:12 <mlavalle> thanks for connecting :-)
14:16:24 <amotoki> I failed to have enough time to review specs and RFEs.
14:16:36 <amotoki> so I would like to cover them next week.
14:17:08 <mlavalle> ok
14:17:34 <mlavalle> yamamoto sent me an email stating that he is not feeling well, so he will not join
14:18:05 <mlavalle> amotoki: are you ok having the meeting today?
14:18:15 <amotoki> mlavalle: I am okay with either.
14:18:22 <mlavalle> or are you propossing to postpone?
14:18:59 <mlavalle> ^^^^
14:20:11 <mlavalle> amotoki: ^^^^
14:20:13 <amotoki> mlavalle: i am okay to have the meeting today
14:20:21 <mlavalle> ok, let's get going
14:21:32 <mlavalle> #topic RFEs
14:22:00 <mlavalle> First RFE we have today is https://bugs.launchpad.net/neutron/+bug/1753466
14:22:01 <openstack> Launchpad bug 1753466 in neutron "[RFE] Support stateless security groups" [Wishlist,Confirmed] - Assigned to Giel Dops (nuage.gieldops)
14:23:01 <mlavalle> You might remember that there was a conversation in Dublin (Friday morning) about implementing stateless firewall with the FWaaS team
14:25:45 <mlavalle> My proposal here is that since we haven't heard back from the submitter, we will implement this as part of FWaaS
14:26:17 <mlavalle> Really bringing it to your attention to see if you agree and mark it as approved
14:26:22 <amotoki> one thing we need to consider seems the relationship between SG  and FWaaS.
14:26:46 <amotoki> SG behaves stateful, so we need to check stateless firewall in FWaaS works well or not.
14:27:25 <amotoki> I think we need to discuss it with fwaas team. they might already cover it.
14:27:50 <mlavalle> stateless in FWaaS is a project that team is pursuing
14:28:32 <mlavalle> In that Friday session in Dublin, they were having their weekly meeting and asked me whether I agreed with it or not
14:28:36 <mlavalle> I said yes
14:28:56 <mlavalle> and yesterday I attended their weekly meeting and they have a section devoted to it
14:29:10 <mlavalle> so I know they are are interested in it
14:29:39 <amotoki> sounds good
14:30:19 <mlavalle> so what I propose is that we mark this RFE as approved on our side
14:30:33 <mlavalle> and I will mention it next week in the FWaaS weekly meeting
14:30:37 <mlavalle> makes sense?
14:31:39 <amotoki> makes sense to me. The RFE says "Support stateless security groups" but it can be replaced with "Support stateless firewall" right?
14:31:40 <haleyb> +1
14:31:57 <mlavalle> yeap, I will do that
14:32:01 <mlavalle> hang on
14:33:51 <mlavalle> Done
14:34:17 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1766380
14:34:19 <openstack> Launchpad bug 1766380 in neutron "[RFE] Create host-routes for routed networks (segments)" [Wishlist,Confirmed]
14:34:44 <mlavalle> You might remember that we started discussing it at the end of our previous meeting
14:40:10 <mlavalle> I think it is a sensible request
14:40:57 <haleyb> yes, i read it again and it makes more sense than last week :)
14:42:58 <amotoki> this makes sense to me too (though I have no experience of using routed networks)
14:43:52 <mlavalle> yeah, he is describing a situation where the behavior of routed networks is not optimal because of the mixing with the other networks
14:44:05 <mlavalle> we didn't think of that when we were implementing routed networks
14:44:25 <mlavalle> This is what we learn when a feature starts to be used
14:44:37 <mlavalle> so I will mark it as approved
14:44:41 <mlavalle> do we all agree?
14:44:58 <amotoki> I am okay to approve it
14:45:03 <haleyb> me too
14:45:05 <amotoki> i have one minor question. should host routes for routed networks be visible via the subnet API.
14:45:10 <amotoki> ?
14:45:37 <amotoki> perhaps it needs a spec and we can discuss it there.
14:45:40 <mlavalle> do you mean as a separate attribute of the subnet
14:45:48 <mlavalle> ?
14:46:09 <amotoki> mlavalle: or we can populate host-routes attribute automatically.
14:46:20 <amotoki> i am not sure which is better at now.
14:46:27 <mlavalle> I think that is exactly what he is proposing
14:47:05 <mlavalle> quoting his words:
14:47:11 <mlavalle> "I believe it would make sense to automate this, so that when additional subnets on additional segments are added the new destination is appended to the host routes"
14:47:49 <amotoki> in my understanding, that is about the behavior of dhcp-agents (or others)
14:48:26 <amotoki> I think he does not mention an API change itself.
14:48:31 <mlavalle> it might be the case
14:48:56 <mlavalle> so you want to make it explicit that it is going to be reflected in the API
14:49:05 <mlavalle> ???
14:49:35 <amotoki> yes, I think it is better to know what is happening via API.
14:49:56 <amotoki> otherwise, VM users might be surprised when they notice extra host routes on their VMs.
14:50:27 <mlavalle> that's a good observation. let me place a comment in the RFE. hang on
14:54:08 <mlavalle> ok, left comment there
14:54:23 <amotoki> thanks
14:54:24 <mlavalle> let's see his response over the next few days
14:55:00 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1768690
14:55:01 <openstack> Launchpad bug 1768690 in neutron "[RFE] Regenerate mac address of a port" [Wishlist,New] - Assigned to Harald Jensås (harald-jensas)
14:55:09 <mlavalle> same submitter
14:56:04 <mlavalle> There is a patch associated to it: https://review.openstack.org/565932
14:57:39 <amotoki> this is about a pre-created port. a MAC address of the port will be changed to an actual MAC based on NIC on a baremetal machine.
14:57:49 <mlavalle> correct
14:58:02 <amotoki> so the first mac address is almost meaningless
14:58:12 <mlavalle> it is
14:58:28 <amotoki> I think regenerating MAC address makes sense when a port is detached.
14:59:27 <mlavalle> his request is just to regenerate the MAC address so it doesn't collide with the next port
14:59:51 <mlavalle> since we are out of time, let's come back to it first thing next week
15:00:05 <mlavalle> #endmeeting