14:00:12 <dougwig> #startmeeting neutron lbaas
14:00:13 <openstack> Meeting started Thu Oct  9 14:00:12 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <sbalukoff> Morning folks!
14:00:17 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:20 <dougwig> #topic roll call
14:00:22 <dougwig> morning folks
14:00:29 <sballe> o/
14:00:34 <dougwig> agenda:
14:00:34 <dougwig> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_09.10.2014
14:00:36 <blogan> hi
14:00:47 <johnsom> Hello
14:00:47 <sbalukoff> rm_work: These do get earlier every week. It's a conspiracy, I tells ya.
14:00:47 <rm_work> o/
14:00:53 <rm_work> yep
14:00:57 * dougwig reaches for coffee.
14:01:00 <rm_work> T_T
14:01:19 <dougwig> #topic Announcements
14:01:29 <dougwig> v2 reviews
14:01:29 <dougwig> #link https://etherpad.openstack.org/p/lbaas_reviews
14:01:47 <dougwig> plugins, tests, and jinja templates are ready for core feedback.
14:02:02 <dougwig> a reminder about the kilo design summit etherpad
14:02:03 <dougwig> #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics
14:02:07 <ptoohill> o/
14:02:14 <dougwig> and we need to re-submit specs for kilo
14:02:18 <dougwig> #link http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo
14:02:25 <dougwig> any other announcements?
14:02:37 <blogan> whenand how do design sessions get approved?
14:02:53 <sbalukoff> blogan: +1
14:02:57 <blogan> i might ask this every week i can't remember
14:03:11 <dougwig> the distilling process started in this week's neutron meeting.
14:03:19 <sballe> blogan: you are not the only one. I believe I do the same ;)
14:03:21 <dougwig> so i think the answer is "soon".
14:03:41 <dougwig> one more announcement from the neutron meeting.  mestery started a drivers team:
14:03:44 <dougwig> #link https://wiki.openstack.org/wiki/Neutron-drivers
14:03:52 <xgerman> drivers?
14:04:13 <dougwig> ml2 mechanisms, vendor stuff, lbaas drivers, etc.
14:04:33 <dougwig> if you recall his plan to move drivers out of neutron core, i'd wager this is the first step.
14:04:34 <xgerman> would octavia be a driver?
14:04:59 <sbalukoff> xgerman: I think 'drivers' refers to people.
14:04:59 <dougwig> that's fuzzy, since we want it to be also the reference implementation
14:05:14 <xgerman> yep, I was afraid of another gray area
14:05:16 <sbalukoff> Because, you know, 'drivers' couldn't possibly already have another meaning in Neutron.
14:05:23 * TrevorV is late....
14:05:49 <dougwig> oh, heh, i hadn't noticed that meaning of drivers.  nice.
14:06:54 <dougwig> i think blogan is correct.  forget what i said.
14:07:01 <sbalukoff> But, having just heard about this (thanks for the link dougwig), I can certainly see the need for such a group.
14:07:07 <blogan> lost my connection, what did i say?
14:07:16 <xgerman> so did I
14:07:26 <dougwig> oops, sbalukoff, not blogan
14:07:27 <xgerman> I am missing part of the conversation
14:07:29 * dougwig reaches for more coffee.
14:07:40 <blogan> lol
14:07:52 <blogan> wish i drank coffee
14:07:57 <dougwig> xgerman: no, i'm missing it.  while having it.  you're fine.
14:08:26 <sbalukoff> xgerman: The 'Neutron Drivers" are a team of people who essentially review specs an determine overall direction for the Neutron project.
14:08:53 <sbalukoff> It appears the initial team here consist of people who spend at least 5-10 hours a week just reviewing specs.
14:08:57 <sballe> We cannot really offer more fuzzy areas .... if the we don;t get things and end up with no velocity
14:09:08 <sbalukoff> No idea how these team members are going to be determined in the future.
14:09:30 <dougwig> someone asked for clarification of that on the ML.
14:09:35 <dougwig> i'd suggest pinging mestery or the ML with questions about the new drivers team or kilo summit deadlines.
14:09:57 <sbalukoff> Cool.
14:10:00 <dougwig> anything else here, or any other announcements, before we move on?
14:10:07 <sbalukoff> In any case, thanks for the heads-up, dougwig
14:10:08 <TrevorV> I'm slightly confused
14:10:24 <xgerman> me and you both
14:10:25 <TrevorV> There is now a team of people called "drivers" that ultimately decide the direction of a project?
14:10:32 <xgerman> looks like a new incubator...
14:10:53 <xgerman> and then there is a drivers project which houses drivers?
14:11:07 <TrevorV> Are they determined by the people in the project or are they appointed?  Is there a form of veto the community can take on these "driver"s decisions?
14:11:39 <xgerman> looks like sbalukoff is advising mestery on being a supreme leader
14:11:39 <sbalukoff> Those are concerns that should probably be brought up and discussed on the mailing list.
14:11:39 <dougwig> ok, let's reset, i confused the issue by linking this to actual drivers at all.  it's not, sbalukoff is correct.
14:12:02 <dougwig> https://www.irccloud.com/pastebin/8QhceG2o
14:12:09 <sbalukoff> xgerman: I'm using jedi mind-control tricks on him.
14:12:28 <sbalukoff> Or rather, sith-lord mind-control techniques.
14:12:35 <TrevorV> dougwig that's the "purpose" for said driver team?
14:12:53 <vjay> So.  Drivers are people then.  Right?
14:13:02 <sbalukoff> vjay: That's what I understand.
14:13:10 <TrevorV> vjay in this instance that is accurate apparently
14:13:21 * TrevorV see what he did there?  Using overloaded terms is fun
14:13:23 <blogan> neutron drivers team sounds like core reviewers, so i dont understand either, but ill just go read the neutron meeting log
14:13:33 <sbalukoff> Think "These people drive the Neutron project forward"
14:13:44 <xgerman> maybe it's a coporations are people thing?
14:13:54 <TrevorV> sbalukoff that's kind of what concerns me.  Who provides that authority to them?
14:13:57 <sbalukoff> I don't know if they were after a "slave drivers" analogy, but they've got it.
14:14:11 <TrevorV> Or maybe that's what you meant needs brought up in the ML
14:14:11 <sbalukoff> TrevorV: Looks like the PTL does
14:14:27 <blogan> TrevorV: who gives core reviewers authority? the PTL does really, not really any different
14:14:46 <blogan> well and other core reviewers
14:14:49 <sbalukoff> In any case, I'm not sure there's anyone here who can address these concerns-- this should probably be discussed on the L
14:14:50 <sbalukoff> ML
14:14:59 <TrevorV> sbalukoff got it.
14:15:17 <dougwig> there is a thread from earlier this week on this very subject.
14:15:21 <sballe> sbalukoff: makes sense
14:15:54 <xgerman> +1
14:16:07 <sballe> dougwig: Should we all reply to that mail or do it in some organized fashion?
14:16:42 <dougwig> we're all part of the neutron team, so i think if you have concerns, we should all just reply.
14:16:51 <sbalukoff> dougwig: +1
14:16:53 <sballe> okey dockey
14:17:22 <dougwig> ok, onwards to more fun:
14:17:24 <dougwig> #topic Floating IP discussion
14:17:33 <sbalukoff> Rad!
14:17:36 <dougwig> blogan, rm_work, ptoohill
14:17:47 <blogan> did we not come to a conclusion on this?
14:17:51 <rm_work> uhh
14:18:00 <blogan> too early in the morning for my brain to work properly
14:18:03 <TrevorV> blogan we decided ptoohill was going to make up a diagram
14:18:07 <sbalukoff> At yesterdays Octavia meeting...
14:18:11 <TrevorV> Or a workflow of each case that we had a concern about
14:18:16 <dougwig> last i heard you wanted to bring it up to the others that attend here, and we had punted pending some use cases.
14:18:18 <sballe> rm_work: I believe you were going to do a sequence diagram of the flow.
14:18:22 <dougwig> not sure if we have anything for this morning.
14:18:22 <sbalukoff> We basically tabled this until we have more specific process (or diagrams) figured out.
14:18:23 <vjay> I think driver should hv control on this.
14:18:26 <ptoohill> Im sorry guys, fighting fire
14:18:34 <rm_work> Was *I* going to do a FLIP flow thing?
14:18:35 <ptoohill> I will work on diagram as soon as i get chance
14:18:44 <TrevorV> rm_work no
14:18:46 <rm_work> k
14:18:54 <dougwig> does one of you want to summarize for the other vendors here, and we can table discussion until next week?
14:18:55 <sballe> rm_work: Sorry my confusion.
14:19:03 <rm_work> it's ok
14:19:09 <rm_work> need the beeps to keep me awake
14:19:18 <sbalukoff> dougwig: Sure
14:19:19 <sballe> rm_work: :-)
14:19:39 <blogan> summary: we may eventually want neutron lbaas to auto allocate a floating ip and associate it with the vip port
14:19:48 <sbalukoff> blogan: +1
14:19:54 <vjay> For example if via is configured as a floating ip.  Driver can attach a floating ip port directly to the backend or can configure a private ip and let the gateway do the nat
14:20:27 <vjay> S/via/vip
14:21:07 <vjay> It depends if backend is in line or parallel to gateway.
14:21:44 <blogan> but would youw ant the neutron api to show the floating ip?
14:22:09 <blogan> sorry neutron lbaas api
14:22:53 <vjay> Yes.  the driver could send it back in the call
14:23:07 <dougwig> the driver isn't involved in 'neutron lb-show-vip'.
14:23:11 <vjay> On what ip has chosen
14:23:39 <blogan> no but the driver can insert something into the database so that when a lb-show-vip happens it can retrieve that
14:24:12 <vjay> Blogan: yes
14:24:15 <dougwig> true
14:25:08 <blogan> well we're still a bit out from actually implementing this, so plenty of time to discuss the logistics of it
14:25:18 <dougwig> ok, so this was just an intro, and the folks that brought this up are doing a more detailed design/flow analysis, and will bring the results back to the group.
14:25:45 <sbalukoff> In any case, it was more or less "decided" at the meeting yesterday that both the current workflow and proposed workflow changes need to be better understood before they can really be contrasted / compared. So I think ptoohill was going to produce some documentation which makes it clearer.
14:25:49 <dougwig> moving on...
14:25:50 <vjay> Also I hv one more scenario.  Let's say 2 vips are created on same network. Driver cannot attach the ports created by lbaas on one backend. It will result in looping scenario
14:25:58 <dougwig> not moving on...
14:26:06 <sbalukoff> :)
14:26:31 <blogan> vjay what is your definition of backend
14:26:32 <vjay> Sorry I type slow... :(
14:26:58 <vjay> Backend == lb  appliance
14:27:04 <sbalukoff> vjay: I think those are excellent concerns to bring up, but should probably wait until we've got more / better documentation on the workflow.
14:27:13 <blogan> yeah true
14:27:22 <sballe> +1
14:27:31 <vjay> Ok.  Will wait.
14:27:38 <sballe> We can adapt the flow to corner cases once we have an agreed upon flow
14:28:05 <sbalukoff> vjay: It might be good to work with ptoohill directly in the "proposed new workflow" to address those concerns pre-emtively, too. ;)
14:28:24 <sbalukoff> sballe: Hopefully, yes!
14:28:39 <vjay> Ok. Sure.
14:29:10 <dougwig> moving on...
14:29:18 <dougwig> #topic Open Discussion
14:29:46 <dougwig> anything else to discuss this morning?
14:30:25 <blogan> is sambercovici here?
14:30:39 <blogan> or any radware people?
14:30:45 <sbalukoff> I'm not seeing him.
14:31:02 <sbalukoff> Or Evgeny
14:31:10 <blogan> well we need to get with him on the talk, since he's the one who set it up
14:31:29 <sbalukoff> Good luck!
14:32:34 <vjay> Never got to discuss on HA.  Any cautions to apply.  Will GARP/VMAC etc work for Vrrp in neutron?
14:33:31 <sbalukoff> Good question. I've no idea. :P
14:34:28 <dougwig> with L2 tunnels, i'm not sure why they wouldn't.  might be tricky to verify that the underlying physical hardware isn't the same, though.
14:36:16 <dougwig> any other discussion, or are we ready to adjourn?
14:36:51 <sbalukoff> Yay for getting back to bed!
14:36:56 <rm_work> sleep plox
14:36:56 <sballe> :)
14:37:05 <dougwig> ok, see everyone in channel!
14:37:08 <sballe> bye
14:37:09 <rm_work> o/
14:37:11 <sbalukoff> Seeya!
14:37:16 <dougwig> #endmeeting