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