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