15:30:29 <mestery> #startmeeting neutron-drivers
15:30:29 <openstack> Meeting started Wed Jun 17 15:30:29 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:33 <openstack> The meeting name has been set to 'neutron_drivers'
15:30:41 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda (same as every week)
15:30:53 <mestery> carl_baldwin: ping if you're here
15:31:13 <carl_baldwin> pong cuz I’m here
15:31:25 <mestery> awesome!
15:31:28 <mestery> OK lets get rolling
15:31:31 <mestery> #topic Spec Discussion
15:31:40 <mestery> #link https://review.openstack.org/#/c/184857/
15:31:41 <mestery> "Get Me a Network"
15:31:56 <mestery> The plan with this one is to work the design out next week in Fort Collins, especially the concurrency issues
15:32:03 <mestery> And once we do that, find someone to implement it :)
15:32:10 <mestery> Any comments?
15:32:11 <mestery> Concerns?
15:32:31 <dougwig> no, that jives with what i thought would work best.
15:33:14 <mestery> cool
15:33:20 <mestery> Next up
15:33:24 <mestery> #link https://review.openstack.org/#/c/169612 Availability zones
15:33:49 <mestery> amotoki had a lot of comments on revision 23 of htis one
15:33:55 <mestery> which need addressing, thanks for hte review amotoki
15:34:03 <amotoki_> AZ one generally looks good. i posted some clarifications.
15:34:23 <mestery> amotoki: Great!
15:34:33 <mestery> I think this is a nice one to get in for Liberty. carl_baldwin dougwig, have you had a chance to review?
15:34:46 <dougwig> i have not
15:34:54 <mestery> OK
15:35:04 <carl_baldwin> mestery: Not much review there.  I can soon if needed.
15:35:23 <hichihara> amotoki: Thank you for your review! I will update tomorrow.
15:35:23 <mestery> carl_baldwin: No worries, I know russellb amotoki and I have reviewed, among others
15:35:24 <dougwig> hmm, i see one issue, though it's small.  ignores services entirely.
15:35:32 <mestery> dougwig: Good catch!
15:35:40 <mestery> And worth a re-spin to accomodate that
15:35:47 <dougwig> i'll comment today
15:35:55 <amotoki_> dougwig: i noticed it too, but it can be deferred I think.
15:36:41 <amotoki_> but it is worth mentioned at least.
15:37:16 <dougwig> amotoki_: yes, it could, though i find it frustrating when features are supported piecemeal.
15:37:24 <mestery> Agreed
15:37:28 <amotoki_> agree.
15:37:49 <mestery> Next up
15:37:53 <mestery> #link https://review.openstack.org/#/c/94612/ VLAN Aware VMs
15:38:04 <mestery> I know armax has been dilligently following up on this, and there was a meeitng yesterday on it
15:38:10 <mestery> armax: Can you summarize if you're around? :)
15:38:53 <mestery> And if armax is busy, the tl;dr is that some progress was made on this one
15:38:54 <armax> mestery: I think we agreed to choose first class citizen for trunk port resource
15:38:59 <mestery> armax: Thanks :)
15:39:07 <armax> they’d need to extend the port resource to track subports
15:39:20 <armax> they’ll respin the patch and hopefully we’ll start seeing some code
15:39:23 <mestery> #info trunk ports will be a first class citizen but subports will be an extension of ports
15:39:26 <mestery> awesome
15:39:28 <mestery> thanks armax!
15:39:30 <mestery> Questions?
15:39:32 <armax> and we’ll take it from there
15:40:15 <amotoki_> there is another spin of the spec, and we can check it.
15:40:23 <mestery> amotoki_: Yes
15:40:35 <dougwig> i think kevinbenton had some issues with subports.  was he at the meeting?  else just flag him to review.
15:40:44 <mestery> He was not there sadly
15:41:01 <armax> dougwig: no he wasn't
15:41:12 <armax> amotoki was there though
15:41:29 <armax> dougwig: we’ll ping him
15:41:39 <amotoki_> armax: ah.... you're right.
15:41:50 <dougwig> cool. i do want to see trunk ports happen.
15:42:26 <armax> we all do
15:42:40 <mestery> OK, last one
15:42:46 <mestery> #link https://review.openstack.org/#/c/172244/ Routed Networks
15:42:48 <mestery> carl_baldwin: This is your baby :)
15:43:03 <mestery> The good news is Kris from godaddy is hopefully going to make the mid-cyclen ext week to discuss this with us
15:43:16 <mestery> And how it can (hopefully) be evolved to address the segment support those folks want
15:43:21 <carl_baldwin> mestery: That is good news.  I look forward to the discussion.
15:43:54 <dougwig> should we put this spec review on hold until the mid-cycle, then?
15:44:19 <carl_baldwin> dougwig: +1
15:44:21 <mestery> dougwig: +1
15:44:27 <carl_baldwin> It could use just a bit more definition.
15:44:40 <amotoki_> +1
15:44:56 <carl_baldwin> … and some validation from others that my ideas are sane would be good.
15:45:02 <dougwig> carl_baldwin: ha, your specs are usually among the most detailed already.  :)
15:45:14 * carl_baldwin blushes
15:45:26 <mestery> carl_baldwin: I know regXoi wants to discuss this in your L3 meeting tomorrow, look for him there
15:45:32 <mestery> He reached out to me this morning on this one
15:45:45 <carl_baldwin> mestery: Thanks, I will look for him.
15:46:19 <mestery> OK, does anyone want to bringup any other particular spec?
15:46:37 <amotoki_> question: are there any important specs in *aaS areas?
15:47:06 <HenryG> Bug #1464465
15:47:06 <openstack> bug 1464465 in neutron "binding_type improvements to simplify Nova interactions" [Undecided,Confirmed] https://launchpad.net/bugs/1464465
15:47:34 <dougwig> amotoki_: for lbaas, the big items are l7 redirection, horizon, and octavia.  l7 was a backlog from kilo, octavia is happening in a different repo, but we do need to talk at some point about how to get horizon support in for lbaas v2.
15:47:52 <dougwig> for fwaas, i think xgerman is putting together use cases in prep for taking a look at maybe a v2 api
15:47:53 <mestery> dougwig: So, lbaas is covered
15:48:01 <mestery> For fwaas, we're in the process of rebooting it a bit, so nothing at this time.
15:48:03 <dougwig> i'm not sure about vpn.
15:48:10 <mestery> dougwig: ++
15:48:18 <mestery> I need to talk to pc_m about vpn today
15:48:27 <amotoki_> dougwig: for horizon support, I can help all efforst and I can discuss offline
15:48:27 <HenryG> Sorry are we not at RFEs yet?
15:48:29 <mestery> It's on my list, it's just not burning me enough to get my attention yet :)
15:48:31 <mestery> HenryG: Not yet
15:48:32 <mestery> :)
15:48:40 <mestery> amotoki_: Awesome, thank you!
15:48:52 <dougwig> amotoki_: ok, let's do that. i'm also interested in if we can do that panel in-repo, instead of having it all in horizon (like the devstack model)
15:48:54 <amotoki_> for vpnaas, I need to clarify what are prioritized.
15:49:30 <amotoki_> dougwig: horizon team are exploring how to scale dahsborad efforts.
15:49:44 <dougwig> amotoki_: ok, we'll take our cue on how to proceed from you, then.
15:49:56 <mestery> Great!
15:50:04 <mestery> Any other specs before we move to RFEs?
15:50:09 <amotoki_> dougwig: I will share efforts in horizon later.
15:50:33 <amotoki_> for vpnaas, I will talk paul what should be prioritized.
15:50:45 <amotoki_> ah... i wrote already..
15:50:58 <mestery> :)
15:51:02 <mestery> OK, lets move to RFEs then
15:51:04 <mestery> #topic RFEs
15:51:11 <mestery> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe RFE bug link
15:51:48 <mestery> HenryG: You had one for us?
15:51:54 <mestery> We can start with yours :)
15:51:59 <HenryG> Bug #1464465
15:52:00 <openstack> bug 1464465 in neutron "binding_type improvements to simplify Nova interactions" [Undecided,Confirmed] https://launchpad.net/bugs/1464465
15:52:11 <HenryG> It's from ijw
15:52:16 <dougwig> better query:
15:52:17 <dougwig> https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=rfe&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&fi
15:52:17 <dougwig> eld.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
15:52:23 <dougwig> man, let me shorten that
15:52:32 <mestery> dougwig: rookie mistake! :)
15:52:44 <dougwig> https://goo.gl/dfUdUf
15:52:52 <dougwig> only new and triaged RFE's.  ^^
15:52:59 <mestery> cool
15:53:37 <HenryG> Why not "confirmed"?
15:54:07 <dougwig> my understanding is that 'confirmed' is 'approved by the drivers/LT'.  do i need to go read that process doc again?  sec.
15:54:22 * HenryG may have wongly set the RFE to confirmed
15:54:29 <mestery> :)
15:54:50 <dougwig> ahh, triaged means approved.
15:54:52 <dougwig> one sec.
15:55:33 <dougwig> https://goo.gl/xtBJkU
15:55:49 <mestery> HenryG: Seems as if the binding RFE proposed by ijw is dependent on a nova spec, true?
15:56:02 <HenryG> mestery: yes
15:56:32 <HenryG> I think he is asking for approval to work on the Neutron side if that goes ahead
15:56:56 <armax> confirmed means they have been acked as RFE bugs
15:56:57 <amotoki_> it seems we need to consider it along with the nova vif script spec.
15:57:19 <armax> triaged means someone from the drivers team has seen them and started working on them
15:57:38 <armax> as in talking and chatting and fighting
15:57:44 <armax> insulting…you name it
15:57:54 <armax> in progress
15:58:26 <armax> is when someone hopelessly start coding believing that the rfe will be made available only to realize that a final -2 will put his/her hopes in tatters
15:58:26 <mestery> rofl
15:58:30 <dougwig> https://goo.gl/xtBJkU   <-- new + confirmed RFE's
15:58:39 <HenryG> I think binding improvements to match Nova is a reasonable request, hence I marked it as confirmed
15:58:44 <mestery> dougwig: How many more URLs will you generate for us?
15:59:01 <mestery> HenryG: cool
15:59:07 <dougwig> mestery: gonna start being some ascii goats soon.
15:59:10 <HenryG> I have no idea if I have the authority to mark as confirmed ;)
15:59:23 <mestery> HenryG: We'll slap you on the wrist if you do something wrong, don't worry
15:59:57 <mestery> I removed the RFE tag from this one: https://bugs.launchpad.net/neutron/+bug/1464190
15:59:58 <openstack> Launchpad bug 1464190 in neutron "Fujitsu Neutron ML2 Mechanism Driver for ISM" [Wishlist,Confirmed] - Assigned to Yushiro FURUKAWA (y-furukawa-2)
16:00:27 <mestery> This one needs an update from the proposer: https://bugs.launchpad.net/neutron/+bug/1457034
16:00:27 <openstack> Launchpad bug 1457034 in neutron "BGPVPN extension" [Undecided,New]
16:00:50 <mestery> We may as well just mark this as triaged: https://bugs.launchpad.net/neutron/+bug/1458890
16:00:51 <openstack> Launchpad bug 1458890 in neutron "Add segment support to Neutron" [Undecided,Confirmed]
16:00:57 <mestery> Because it's gonna happen, so many operators need this one
16:01:14 <amotoki_> For such cases, do we set the status to Imcomplete? or keep it New?
16:01:38 <amotoki_> i am talking about BGPVPN one.
16:01:40 <mestery> amotoki_: We set it to "Triaged"
16:01:52 <mestery> amotoki_: Lets leave it as "Confirmed" since we've alreayd looked at it
16:02:10 <mestery> Thoughts on https://bugs.launchpad.net/neutron/+bug/1460720 ???
16:02:11 <openstack> Launchpad bug 1460720 in neutron "Add API to set ipv6 gateway" [Undecided,New] - Assigned to Abishek Subramanian (absubram)
16:02:18 <dougwig> we need a wiki page or doc cheat sheet.  "rfe bug states for dummies"
16:02:21 <dougwig> <-- the dummy
16:02:35 <mestery> #action dougwig to write "RFE for dummies" page
16:02:40 <mestery> dougwig: Sound good? ;)
16:02:42 <mestery> You see what I did there?
16:02:45 <HenryG> lol
16:02:47 <dougwig> lol, fine.  :)
16:02:51 <amotoki_> :-)
16:03:18 <HenryG> mestery: that RFE can at least be marked confirmed
16:03:29 <mestery> HenryG: done
16:03:52 <mestery> HenryG: It's an API change, but it seems sensible to me.
16:04:03 <HenryG> It was discussed but I have not seen any work started yet
16:04:15 <HenryG> (in the L3 meeting)
16:04:15 <mestery> HenryG: I am fine moving this to triaged and allowing work to proceed
16:04:19 <mestery> anyone have any issues there?
16:04:22 <mestery> going once
16:04:24 <mestery> going twice
16:04:27 * mestery waits for 30 seconds
16:04:32 <carl_baldwin> +1
16:04:40 <HenryG> Thanks carl_baldwin
16:04:42 <mestery> sold to carl_baldwin ! :)
16:04:42 <carl_baldwin> We came up with a good plan, I think.
16:04:45 <mestery> triaged it is!
16:04:52 <HenryG> yay
16:05:04 <mestery> Now on to armax's favorite RFE: https://bugs.launchpad.net/neutron/+bug/1461133
16:05:05 <openstack> Launchpad bug 1461133 in neutron "Supporting multiple L3 backends" [Undecided,Confirmed]
16:05:12 <carl_baldwin> Just as long as sold to doesn’t mean assigned to
16:05:19 <mestery> carl_baldwin: lol
16:05:22 <HenryG> heh
16:06:10 <mestery> I think everyone thinks we need ML3
16:06:16 <amotoki_> It is actually ML3 work. it sounds reasonable
16:06:18 <mestery> And I think the way forward is to use flavors (where's dougwig and my flavors update)
16:06:27 <mestery> amotoki_: Lets move this one to Triaged then and be done with it
16:06:32 <mestery> We can iterate more on the code and devref
16:06:43 <amotoki_> mestery: agree.
16:06:57 <mestery> cool, done!
16:06:58 <mestery> next up
16:07:04 <mestery> https://bugs.launchpad.net/neutron/+bug/1463594
16:07:05 <openstack> Launchpad bug 1463594 in neutron "LBaaS drivers can be queried to determine whether they support a feature the API exposes" [Undecided,Confirmed]
16:07:08 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1463594
16:07:16 <mestery> I discussed this with blogan and dougwig yesterday I believe
16:07:28 <mestery> The result is mentioned in comment #4
16:07:34 <mestery> blogan will write a spec with specific use cases
16:07:40 <mestery> Because an RFE for this one wasn't enough
16:07:43 <mestery> dougwig: Did I capture that accurately>?
16:07:49 <dougwig> yes, we can punt this until we see a spec.
16:08:06 <mestery> cool
16:08:19 <mestery> OK, next up:
16:08:21 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1464361
16:08:22 <openstack> Launchpad bug 1464361 in neutron "Support for multiple gateways in Neutron subnets" [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)
16:08:33 <mestery> carl_baldwin: I think you'd want to review this one
16:08:50 <kevinbenton> i'm leaning towards -1
16:08:54 <kevinbenton> requires data model changes
16:08:58 <kevinbenton> and dhcp agent changes
16:09:00 <mestery> kevinbenton: Was thinking the same
16:09:10 <mestery> kevinbenton: Ignore the implmentation details for a minute
16:09:15 <mestery> THe use case seems valid to me
16:09:18 <mestery> Agree?
16:09:49 <kevinbenton> maybe
16:09:56 <mestery> carl_baldwin: your thoughts on the use case?
16:09:56 <amotoki_> use cases looks valid
16:09:58 <mestery> maybe?
16:10:02 <kevinbenton> is it common to give servers different gateways in the same subnets?
16:10:09 <amotoki_> but i am not sure the approach looks good or not.
16:10:40 <mestery> kevinbenton: Lets comment on the bug, if the use case is valid, we can then work a solution
16:10:43 <carl_baldwin> I’m not sure how common this is.  I’ve never seen it but that does mean much.
16:10:45 <mestery> Thus, the RFE process in action!
16:12:00 <mestery> I've commented and marked it confirmed
16:12:12 <mestery> Last one
16:12:13 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1464793
16:12:14 <openstack> Launchpad bug 1464793 in neutron "Add a driver for isc-dhcpd" [Undecided,New] - Assigned to Shraddha Pandhe (shraddha-pandhe)
16:12:34 <kevinbenton> +1
16:12:39 <kevinbenton> only question is where it should live
16:12:55 <mestery> right
16:12:59 <mestery> you mean, in it's own repo?
16:13:15 <kevinbenton> yeah, or do we just pull it into neutron?
16:14:04 <mestery> I would not like to pull this in, if we do the reference split (still on the table), it could go in that repo
16:14:25 <amotoki_> I am not sure the current neutron driver impl can support proper driver mechanism
16:14:34 <mestery> amotoki_: There's also that :)
16:14:35 <amotoki_> after ref split, we can do it in that repo.
16:15:01 <dougwig> i think it's a no brainer to confirm this one, though.
16:15:03 <amotoki_> yeah, we have, but we only support dnsmasq at now.
16:15:24 <kevinbenton> i guess it can just go in wherever the reference lives for now
16:15:25 <mestery> dougwig: Already confirmed
16:15:31 <mestery> and commented based on this discussion
16:15:57 <mestery> That was the last RFE
16:16:00 <mestery> #topic Open Discussion
16:16:08 <mestery> Anything else or shall we close this meeting?
16:16:37 <kevinbenton> shall we discuss the deadlock issue really quick?
16:16:45 <mestery> kevinbenton: Please, go ahead!
16:16:56 <mestery> I know carl_baldwin is here and you have been discussing that with him on the ML, so yes, makes sense
16:17:12 <kevinbenton> it has come to my attention that with galera multi-master, any random thing can deadlock to test a programmers patience
16:17:40 <kevinbenton> should we just jam the retry mechanism high up in the API layer for every operation and call it a day?
16:18:11 <mestery> I'd be curious what jaypipes has to say about that given his DB experience kevinbenton.
16:18:21 <mestery> Have you run that by him by chance?
16:18:26 <dougwig> what's the root of the issue?  crazy txn nesting?  not locking tables in a defined order?
16:18:28 <carl_baldwin> mestery: +1
16:18:30 <kevinbenton> i will in my secret meeting with him in 10 minutes
16:18:34 <mestery> rofl
16:18:40 <kevinbenton> and have him reply to the ML
16:18:44 <mestery> OK, let us know how it goes, his guidance is apprecaited
16:18:46 <mestery> cool
16:18:50 <HenryG> We should also make sure keep zzzeek in the loop
16:18:54 <mestery> +1
16:19:02 <kevinbenton> dougwig: transactions are verified after they are committed
16:19:03 <carl_baldwin> dougwig: There is a thread you should catch up on.
16:19:22 <dougwig> how did i miss this thread?  ok, i'll go look.
16:19:29 <kevinbenton> dougwig: so once galera realizes it regrets it commitment, it throws a deadlock
16:19:58 * mestery points dougwig at this thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067059.html
16:19:58 <HenryG> dougwig: the thread is titled "quota enforcement" to throw you off the trail
16:20:00 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/067059.html
16:20:04 <mestery> kevinbenton carl_baldwin: That's the one, right?
16:20:16 <kevinbenton> mestery: yeah
16:20:20 <mestery> cool
16:20:26 <carl_baldwin> HenryG: Thanks for beating me to getting the link
16:20:28 <kevinbenton> it led to that topic because the discussion of locks came up
16:20:33 <carl_baldwin> er, mestery
16:20:43 <mestery> ???
16:20:50 <dougwig> ty
16:20:54 <kevinbenton> mestery: stop beating carl_baldwin
16:20:55 <carl_baldwin> Thanks mestery for getting the link.
16:21:10 <mestery> rofl
16:21:13 <mestery> OK, lets close this thing down.
16:21:26 <mestery> Thanks for all your hard work and guidance folks!
16:21:28 <mestery> #endmeeting