22:00:45 <dougwig> #startmeeting neutron_drivers
22:00:46 <openstack> Meeting started Thu Jun 23 22:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:47 <johnsom> o/
22:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:51 <openstack> The meeting name has been set to 'neutron_drivers'
22:01:02 * haleyb is just a passenger
22:01:12 <dougwig> welcome to neutron drivers, specs edition.
22:01:25 <dougwig> armax asked us to take a pass through the open specs, instead of RFEs, this week.
22:02:14 <HenryG> https://review.openstack.org/#/q/project:openstack/neutron-specs+status:open ?
22:02:14 <dougwig> so, without further ado, hopefully this isn't the first time we've seen them all, vote, or punt, or let's have whatever discussions we need to have:
22:02:21 <dougwig> Add flavor support to the L3 plugin
22:02:21 <dougwig> https://review.openstack.org/#/c/105078/
22:03:08 <dougwig> kevinbenton: how this one going?
22:03:35 <kevinbenton> dougwig: going along. doing some groundwork for exception handling stuff for callbacks
22:03:50 <kevinbenton> dougwig: need to sync up with armax when he gets back to go over some interface stuff
22:04:04 <kevinbenton> dougwig: still a few weeks out
22:04:05 <dougwig> anything contentious, or anything we can nudge along?
22:04:37 <kevinbenton> no, nothing that like
22:04:40 * carl_baldwin wanders in late. He's sorry he wasn't watching the clock.
22:04:55 <dougwig> no worries, it just means your chair next week.
22:05:15 <dougwig> next up, Diagnostics of Neutron components
22:05:15 <dougwig> https://review.openstack.org/#/c/308973/
22:05:50 <dougwig> this looks far from consensus.
22:06:17 <dougwig> just judging from recent comment volume.
22:07:32 <amotoki> is amuller the right person to ask the status?
22:07:49 <dougwig> yes. though looking at it, i'm guessing we're not going to see any code in newton.
22:08:17 <dougwig> let's move to some smaller stuff.
22:08:20 <dougwig> Minimum bandwidth support (egress)
22:08:20 <dougwig> https://review.openstack.org/#/c/316082/
22:08:54 <dougwig> lots of activity, but no drivers have commented yet.
22:09:36 <amotoki> In my understanding, API and general direction are agreed.  i think now they are discussing more technical details on ovs impl.
22:10:31 <HenryG> Does it depend on a generic flow classifier (which may be its own BP/RFE)?
22:10:53 <amotoki> I don't think there is an depedency to generic FC.
22:11:01 <HenryG> OK
22:11:10 <amotoki> as far as I reviewed a week ago.
22:12:02 <dougwig> these first few are high priorities for newton, so i expect they're more active.  later on, we get to some fun ones that seems to bypass our rfe process.
22:12:17 <dougwig> moving on. Enhanced Network/Subnet DHCP Options
22:12:18 <dougwig> https://review.openstack.org/#/c/247027/
22:12:46 <amotoki> aga... i forgot to respond to sam
22:13:02 <dougwig> looks like amotoki has been active in this one.
22:13:19 <dougwig> Added a note on OSC client coverage for new CLI features
22:13:19 <dougwig> https://review.openstack.org/#/c/331592/
22:13:51 <dougwig> in openstack's continuing quest to constantly change interfaces, here we go.
22:15:03 <amotoki> just a note. in a neutronclient review, there is a discussion on whether we should have a feature in OSC itself or OSC plugin in neutronclient repo.
22:15:48 <dougwig> as in, whether we implement new neutron commands in the osc repo, or via some plugin, or what?
22:16:27 <amotoki> the dicsussion happens for vlan-aware-vm OSC support.
22:16:45 <dougwig> what's the current plan?
22:16:54 <amotoki> armando suggested to implement it as OSC plugin in neutronclient.
22:17:03 <HenryG> +1
22:17:27 <dougwig> so, new commands will be osc only, then?
22:17:47 <amotoki> the current general consensus seems that experimental features in neutron repo should go to neutornclient (OSC plugin)
22:18:16 <amotoki> neutron CLI is optional.
22:19:01 <dougwig> ok.  amotoki, are you going to follow the spec above?  311592 ?
22:19:09 <amotoki> sure
22:19:16 <dougwig> L2 extension ovs flow management
22:19:16 <dougwig> https://review.openstack.org/#/c/320439/
22:21:31 <dougwig> this one also has code in gerrit.
22:23:00 <amotoki> this one requires discussion as code. I am not sure we land it in newton.
22:23:30 <amotoki> how many efforts depend on this?
22:24:03 <dougwig> it's an approved rfe, but i didn't see it targeted for newton.
22:24:44 <dougwig> alright, here's one that usually gets people arguing - (Operator-only) Logging API for security groups
22:24:44 <dougwig> https://review.openstack.org/#/c/203509/
22:24:52 <dougwig> and it is targeted at n-2
22:27:38 <dougwig> is this headed in the right direction, or do we need to give it some guidance?
22:28:33 <kevinbenton> I haven't had a chance to review this one for awhile
22:28:45 <kevinbenton> Need to see the latest state
22:29:06 <amotoki> last time i checked (two weeks ago), it wasn't in a wrong direction.
22:29:10 <kevinbenton> I think everyone was okay with the feature, the issue was decoupling the logging implementation from the API
22:29:45 <dougwig> alright.  maybe we'll breeze through the ones with lots of activity here.
22:29:49 <dougwig> Spec for distributed portbindings
22:29:50 <dougwig> https://review.openstack.org/#/c/309416/
22:30:13 <kevinbenton> Also need to review this
22:30:44 <dougwig> this one is about binding a port to multiple hosts, for migration, though failover can't be far behind.
22:30:59 <kevinbenton> Well also to make DVR less special
22:31:05 <dougwig> which starts to look like loadbalancing, too.
22:31:09 <kevinbenton> Right now it's special cased everywhere
22:31:20 <dougwig> i'm all for fewer snowflakes.
22:31:25 <carl_baldwin> I also need to read this.  Was starting to review the code patches.
22:31:38 <dougwig> ok.
22:31:47 <johnsom> If this fixes the DVR FLIP bug I would be a happy camper
22:32:01 <dougwig> here's one that i'm surprised is still kicking around:
22:32:05 <dougwig> Add timestamp to neutron extension resources
22:32:05 <dougwig> https://review.openstack.org/#/c/223988/
22:32:10 <carl_baldwin> johnsom: Which bug?
22:32:15 <kevinbenton> johnsom: that refers to about 100 bugs, need to be more specific
22:32:29 <kevinbenton> :)
22:32:38 <dougwig> haha
22:32:42 <johnsom> Ah, sorry, Floating IPs don't work with allowed address pairs ports when DVR is enabled
22:32:58 <kevinbenton> Ah, right
22:32:58 <dougwig> timestamp spec was last updated 7 weeks ago, has no +1's even.  anyone here want to champion it, or shall we abandon?
22:33:12 <kevinbenton> dougwig: I might look at it
22:33:25 <kevinbenton> dougwig: we already have timestamps on core resources
22:33:42 <kevinbenton> dougwig: and timestamps likely already exist on the models for them
22:33:56 <kevinbenton> dougwig: it's just a matter of API exposure I think
22:33:59 <dougwig> id's and timestamps on every db object is one of those things that's a no-brainer to me, so i'm suprised it's been open so long.
22:34:41 <kevinbenton> I'll ping on the spec to see if submitter is still interested
22:34:47 <dougwig> ok
22:35:01 <dougwig> next one came out of summit discussions, and was just revised.  LBaaS project spinout
22:35:01 <dougwig> https://review.openstack.org/#/c/310805/
22:35:04 <kevinbenton> johnsom: I'm not sure if that will solve the floating ip bug btw
22:37:31 <amotoki> Re Lbaas spinout, I haven't caught up with the whole discussion. do we all agree to spinout?
22:37:57 <dougwig> i don't think it was controversial.
22:38:09 <kevinbenton> Yeah, it's okay with me.
22:39:01 <dougwig> next up, ipv6 fun.  Spec for IPv6 support in metadata service
22:39:01 <dougwig> https://review.openstack.org/#/c/315604/
22:39:07 <amotoki> it's okay to me too. one thing to note is about db migration. how can we migrate neutron migration to loadbalancer project?
22:39:15 <amotoki> i'lll leave a comment on the review.
22:39:34 <dougwig> metadata always goes to ipv4 today, i take it?
22:39:37 <dougwig> amotoki: thanks
22:39:59 <kevinbenton> Metadata service needs to match whatever cloud init does
22:40:09 <kevinbenton> IIRC cloud init doesn't request via ipv6
22:40:18 <kevinbenton> So what does this accomplish?
22:40:22 <johnsom> kevinbenton yeah, I agree looking at it
22:41:19 <dougwig> it looks like they're trying to define an ipv6 mechanism, which then cloud-init or config drive would have to support, right?  does config drive even care about v4 vs v6?
22:41:26 <HenryG> I think the thought is to support IPv6 only environments.
22:41:38 <kevinbenton> Config drive doesn't use metadata
22:41:46 <kevinbenton> But cloud init would require a change
22:41:50 <kevinbenton> Which we don't own
22:42:10 <kevinbenton> So this requires coordination with cloud init devs
22:42:11 <dougwig> config drive is just another way to shove metadata in, though.  it obsoletes cloud-init magic URLs.
22:42:20 <carl_baldwin> This has come up a bunch of times before, right?
22:42:35 <kevinbenton> I know, but this is the metadata service we are talking about, not cloud init
22:43:12 <amotoki> but we need to sync cloud-init :)
22:43:41 <kevinbenton> harlowja: I summon thee!
22:43:53 * harlowja comes to life
22:43:58 <haleyb> i had a number of comments on this spec, mostly about basically creating a well-known IPv6 address that is used for metadata, that usually requires an rfc
22:44:00 <harlowja> soul please
22:44:01 <harlowja> lol
22:44:02 * dougwig can smell the heating tar.
22:44:02 <kevinbenton> harlowja: we want cloud init changes
22:44:08 <harlowja> soul please?
22:44:09 <harlowja> lol
22:44:15 <njohnston> It's ALIVE!!
22:44:27 <harlowja> sup
22:44:37 <kevinbenton> IPv6 cloud init support
22:44:44 <harlowja> k
22:44:48 <kevinbenton> CAN IT BE DONE?
22:44:51 <harlowja> should work
22:44:56 <harlowja> already did it, lol
22:45:03 <dougwig> harlowja: see here - https://review.openstack.org/#/c/315604/
22:45:08 <kevinbenton> Oh, you should comment on spec then
22:45:18 <dougwig> we were just discussing if it makes any sense / needs direction / whatnot.
22:45:34 <harlowja> ah, u want it in the metadata service
22:45:46 <harlowja> so there is network_data.json that has this already
22:45:49 <dougwig> the spec does, i'm not sure we do.
22:45:50 <harlowja> or should have it
22:46:03 <kevinbenton> Yeah, right now cloud init does 169.254.169.254
22:46:16 <kevinbenton> We need a well know IPv6 only mechanism
22:46:16 <harlowja> oh that address
22:46:24 * dougwig disparages ipv6, thus summoning sc68cal
22:46:25 <harlowja> not the configuration of the network that the VM gets
22:47:18 <dougwig> alright, we've stirred the pot on this one, let's take it to the spec.
22:47:28 <dougwig> next up, Add Unicast Flooding Vteps to Provider Network
22:47:28 <dougwig> https://review.openstack.org/#/c/282180/
22:47:45 * harlowja turns into dust
22:47:51 <kevinbenton> harlowja: thx
22:47:57 * harlowja is already dust
22:47:58 <harlowja> lol
22:48:07 <dougwig> heh
22:48:21 * njohnston puts sc68cal back in his Pokeball
22:48:22 <dougwig> that vtep spec sounds like a similar use case to l2gw, doesn't it?
22:49:11 <kevinbenton> dougwig: it's a little different
22:49:29 <kevinbenton> dougwig: right now  we just have inferred targets for VXLAN
22:49:36 <kevinbenton> dougwig: based on agent IP addresses, etc
22:49:44 <kevinbenton> dougwig: bringing them into binding makes it more explicit
22:49:52 <kevinbenton> and easier interop between different devices
22:50:02 <kevinbenton> (e.g. a top of rack switch, a router, whatever)
22:50:14 <kevinbenton> or even different vswitch types
22:51:43 <dougwig> kevinbenton: ok, want to take a crack at reviewing that spec later?
22:51:47 <kevinbenton> yeah
22:51:54 <kevinbenton> i have already reviewed some of the patches
22:52:00 <dougwig> ok.
22:52:01 <kevinbenton> didn't realize they actually did have a spec for it
22:52:28 <dougwig> we have 8 minutes to squeeze in some RFE's, unless anyone had any comments on any of the prior specs.
22:52:29 <dougwig> https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Confirmed&field.tag=rfe
22:52:46 <kevinbenton> No rfes! I'm drowning!
22:53:01 <carl_baldwin> +1
22:53:03 <carl_baldwin> :)
22:53:25 <amotoki> :)
22:53:43 <amotoki> we need to request BGP folks to revisit BGP related RFEs.
22:54:01 <dougwig> heh, ok, we'll punt RFE's until next time.
22:54:13 <carl_baldwin> amotoki: We did revisit those.
22:54:15 <dougwig> please use the extra six minutes, and more today/tomorrow, and give specs reviews some love.
22:54:31 <carl_baldwin> I'm wondering why we're going through the list of Confirmed instead of Triaged.
22:54:32 <amotoki> carl_baldwin: nice. thanks
22:54:52 <carl_baldwin> I moved most of the BGP specs to Confirmed to get them off the Triaged list.
22:54:55 <dougwig> carl_baldwin: i was stealing the link from last meeitng, and noticed it was the wrong list.
22:55:00 <carl_baldwin> But, maybe I still don't understand our process.
22:55:05 <carl_baldwin> :)
22:55:11 <amotoki> https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:55:50 <dougwig> thanks amotoki
22:55:58 <dougwig> ok, happy spec reviewing.
22:56:04 <dougwig> #endmeeting