14:00:43 <mestery> #startmeeting neutron lbaas
14:00:44 <dougwig> hi
14:00:45 <openstack> Meeting started Thu Jun 12 14:00:43 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:48 <Guest48894> Hi
14:00:49 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:55 <blogan> hello
14:00:59 <mlavalle> hello
14:01:06 <mestery> enikanorov indicated he couldn't make today's meeting, so you're all stuck with me today. :P
14:01:17 <mestery> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_12.06.2014 Agenda
14:01:18 <blogan> noooooooooooooo
14:01:20 <blogan> j/k
14:01:22 <mlavalle> that's cool mestery
14:01:24 <mestery> blogan: Ha! :)
14:01:30 <sballe> morning.
14:01:35 <mestery> sballe: Good morning!
14:01:48 <mestery> OK, per the agenda, I only see two things.
14:01:56 <mestery> Does anyone want to add anything to agenda at this point?
14:02:42 * mestery crickets :)
14:02:49 <mestery> OK, lets move along then!
14:02:52 <mestery> #topic Hackathon Updates
14:03:07 <mestery> We should be all set for next week in San Antonio (with Hangouts and IRC access for remote people).
14:03:09 <blogan> i know one thign we need to do is get a document out defining the request and response's the new API will have
14:03:17 <mestery> blogan: +1
14:03:28 <blogan> but I think Stpehn and I will be attempting to get that out before the hackathon
14:03:37 <sballe> and sbalukoff signed up to that. right?
14:03:51 <mestery> blogan sbalukoff: Great!
14:04:10 <sbalukoff> Again, I will not be offended if someone else does that before I do.
14:04:10 <rm_work> o/
14:04:10 <mestery> blogan: At some point, you need to let us know where at RAX to land on Tuesday morning :)
14:04:25 <sbalukoff> Since I do have limited availability to do so in the next couple of days.
14:04:36 <sballe> mestery, We update the etherpad yesterday with the right address :)
14:04:46 <sbalukoff> Also, agenda-ish thing for the hackathon:
14:04:51 <sbalukoff> #link https://etherpad.openstack.org/p/1gsTm4GBdu
14:04:59 <sbalukoff> And where to go:
14:05:03 <mestery> sballe: Thanks! ;)
14:05:15 <sbalukoff> #link https://etherpad.openstack.org/p/neutron-juno-lbaas-mid-cycle
14:05:17 <sballe> mestery, Address is at: https://etherpad.openstack.org/p/neutron-juno-lbaas-mid-cycle
14:05:28 <mestery> #link https://etherpad.openstack.org/p/neutron-juno-lbaas-mid-cycle
14:05:40 <mestery> sballe: Perfect! Now I know where to be Tuesday.
14:05:41 <blogan> mestery: all you have to do is come in the front doors and tell them you have to go to the customer experience center
14:05:49 <mestery> blogan: Awesome!
14:06:04 <samuelbercovici> hello
14:06:05 <blogan> it'll be directly to the left of the front desk
14:06:38 <mestery> Anything else Hackathon-ish for next week?
14:06:43 <mlavalle> mestery: as I undertsnad it, breakfast will be served every morning
14:06:53 <sbalukoff> And lunch!  Yay!
14:07:00 <dougwig> the customer experience center?  do we sit in a dark room and click 'launch instance' until our credit card bill makes us want to cry?  :)
14:07:00 <sballe> the food is good.
14:07:02 <mestery> mlavalle: Wow, very nice!
14:07:09 <dougwig> since that is the "customer experience".  :)
14:07:10 <mestery> dougwig: :P
14:07:34 <blogan> dougwig: only you will be doing that
14:07:40 <sballe> blogan, +1
14:07:43 <rm_work> lol dougwig
14:07:50 <sbalukoff> Heh!
14:07:54 <dougwig> :)
14:08:03 <mestery> blogan: You will get us wifi access once we arrive?
14:08:03 <jorgem> I'll add the specific room numbers on the wiki
14:08:10 <mestery> blogan: Or do you need something prior to that to setup access?
14:08:12 <blogan> mestery: it is already set up
14:08:17 <mestery> blogan: Awesome!
14:08:19 <rm_work> mestery: the customer experience center will have a user/pass for you guys to use
14:08:24 <mestery> blogan: You guys run a tight ship :)
14:08:26 <jorgem> but the host should lead you to the right area
14:08:28 <mestery> rm_work: Thanks!
14:08:33 <sbalukoff> jorgem: You mean the etherpad?
14:08:40 <jorgem> correct
14:08:42 <jorgem> sorry
14:08:44 * mestery wonders if the Spurs will be NBA Champs by the time we arrive next week :)
14:09:00 * mestery realizes he doesn't follow basketball that close and the Spurs could already be NBA champs.
14:09:04 <jorgem> mestery: Yes be careful of crazy fans downtown whenever we win a game
14:09:10 <mestery> jorgem: :)
14:09:11 <s3wong> mestery: if so, perhaps we will just be there for the parade...
14:09:11 <jorgem> mestery: And traffic
14:09:14 <blogan> mestery: if you're staying downtown and they do win then you'll see downtown getting shutdown
14:09:17 <vjay4> GoSpursGo
14:09:35 <mestery> blogan jorgem: I'm at the Aloft airport hotel, don't think that's downtown.
14:09:47 <sballe> blogan, Wow cool! I saty downtown
14:09:49 <blogan> mestery: no it's not
14:09:52 <mlavalle> mestery: no that is not downtown
14:10:03 <mestery> Great!
14:10:06 <jorgem> mestery: correct but a cab ride downtown is less than 15 mins
14:10:13 <mestery> jorgem: Nice!
14:10:39 <german__> and Austin is 2 hours or so away :-)
14:10:44 <blogan> mestery: how will the hackathon work next week? we will be workign on blueprints and getting that code in quickly?
14:10:47 <rm_work> I think San Antonio has Lyft now, and Uber is starting but they are not very big yet so it is hard to get them
14:10:53 <sballe> when are they playing? Sorry I am out of touch with any sport that is not soccer ;-)
14:10:58 <mestery> blogan: Ideally, yes, we can cracnk code, do reviews, and try to merge code.
14:11:05 <rm_work> but I cannot comment on how well either work here, really
14:11:06 <sbalukoff> mestery: Just FYI, one of the things high on the piority list for next week are the Neutron interface cleanup stuff.
14:11:22 <mestery> sbalukoff: Absolutely! Myself and markmcclain are ready for that.
14:11:24 <sballe> sbalukoff, mestery +1 Same here
14:11:31 <blogan> mestery: will we try to get code in to clean up the tight integration points as well?
14:11:32 <sbalukoff> Cool beans!
14:11:38 <mestery> sbalukoff: We want to make sure we have those interfaces hardened for when LBaaS departs Neutron ;)
14:11:40 <sballe> mestery, can you send them out ahead of the meeting ?
14:11:44 <blogan> sbalukoff beat me to it
14:11:49 <mestery> blogan: Hopefully, yes!
14:11:57 <sbalukoff> Also, the sooner we can get that list of gaps from your perspective, the better! XD We absolutely wouldn't complain if we saw the list this week. :D
14:12:06 <mestery> sballe: I'll see if I can do that, need to work with markmcclain on that front.
14:12:21 <sbalukoff> Cool!
14:12:25 <mestery> sbalukoff: Cool. Like you, my time is somewhat constrained the next two days :(
14:12:40 <sbalukoff> Yep, I hear you.
14:13:13 <rm_work> mestery: well, there's always the weekend :)
14:13:16 <sballe> mestery, sbalukoff same here :( Work related and not work related styff. My youngest is turning 9 and we have plans to have kids all over the house this wekend
14:13:18 <mestery> rm_work: :P
14:13:30 <jorgem> Did everyone see my "weekly standup" etherpad doc?
14:13:36 <sbalukoff> sballe: Nice!
14:13:38 <sballe> jorgem, Yes I like it.
14:13:41 <mestery> sbalukoff: Happy birthday to the youngest! I have a soon-to-be 10 year old in 3 weeks :)
14:13:43 <jorgem> mestery: Was wondering about your thoughts on that.
14:13:47 <mestery> sballe:
14:13:57 * mestery is beginning to dislike autocorrect
14:14:06 <mestery> jorgem: Lets move to that item now.
14:14:12 <mestery> #topic Standup Etherpad
14:14:17 <mestery> #link https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup
14:14:21 <mestery> jorgem: Do yo uwant to drive this section?
14:14:24 <jorgem> sure
14:14:28 <mestery> jorgem: thanks!
14:14:29 <jorgem> So...
14:14:50 <jorgem> Since there are a lot of people involved I wanted a way to get visibility on a weekly cadence
14:15:12 <jorgem> that way we don't step on eachothers toes and can effectively use our resources
14:15:15 <sbalukoff> I like it.
14:15:22 <aburaschi> ( o/ )
14:15:23 <mestery> +1
14:15:28 <german__> +1
14:15:35 <dougwig> +1
14:15:35 <jorgem> The idea is everyone updates the etherpad before the weekly IRC meeting
14:15:36 <sbalukoff> And it means as a group we can potentially do more than 3-4 action items per week.
14:15:56 <jorgem> part of the agenda is to ask any questions about the standup
14:16:00 <sbalukoff> Which is great because we have so many people involved in this. :D
14:16:10 <jorgem> plus it should help us divvy out action items
14:16:37 <german__> yeah, I was looking for that scrum-of-scrum when we started coding
14:16:45 <jorgem> don't think it is the "openstack" way but I'd like to try it out for a few weeks and see how it works
14:16:45 <mestery> jorgem: This is a great idea, I like it!
14:16:53 <jorgem> mestery: awesome
14:17:22 <sbalukoff> Is there a more "openstack" way of doing this sort of thing?
14:17:25 <jorgem> It would be nice to add a friendly reminder to the agenda email we send out every week too
14:17:33 <mestery> jorgem: +1
14:17:37 <sbalukoff> +1
14:17:42 <dougwig> +1
14:17:43 <vjay4> +1
14:17:51 <sballe> I agree but I want to make sure anybody can add themselvs to the list and contribute.
14:18:03 <german__> it's an etherpad...
14:18:05 <jorgem> Its a little bit of an overhead which is why I have only one person from each team responsible ie the contact
14:18:23 <sballe> Oh I was just thinking if somebody new wanted to join the party
14:18:27 <jorgem> so I update for Rackspace, Susanne for HP, etc.
14:18:40 <sballe> I agree on the one person representign a company
14:18:40 <jorgem> someone new can surely do that
14:18:59 <jorgem> its by no means a dogmatic approach
14:19:05 <sballe> Is everybody ok if I had this page to the Wiki?
14:19:15 <german__> +1
14:19:15 <sbalukoff> sballe: Please do!
14:19:16 <atiwari> o/
14:19:21 <sballe> Since it is part of our process I would like it to be on the Wiki
14:19:22 <dougwig> +1
14:19:28 <jorgem> sballe: I'm fine with that, related however is ALL the links we have
14:19:40 <jorgem> I'm loosing track of all the etherpads we have
14:19:46 <jorgem> losing*
14:19:48 <german__> me too
14:19:48 <blogan> we've got a hornet's nest of etherpads
14:19:53 <vivek_ebay> thats true
14:19:53 <sballe> I already added many of the links and reorganized the Wiki page to fir "my" needs
14:20:26 <jorgem> mestery: How do people usually organize all of the etherpad docs out there?
14:20:29 <sballe> My totally selffish view is taht I need all the links on the wiki LBaaS homepage so I can find thme
14:20:48 <mestery> jorgem: Sticky notes. :)
14:20:57 <mestery> jorgem: To be honest, it's a challenging problem.
14:21:03 <sbalukoff> It surely beats the folder of bookmarks I've been making in my browser. :P
14:21:08 <mestery> jorgem: I recommend links from a wiki page, that seems to help.
14:21:19 <jorgem> mestery: Gotcha, how about a relevant links central wiki page?
14:21:22 <mestery> sbalukoff: Or leaving tabs open, which is my standard way
14:21:36 <mestery> jorgem: Perfect! We may need to groom it occasionally, but it's doable.
14:21:43 <jorgem> well, the weekly standup doc should also help
14:21:49 <sballe> mestery, Yeah that was my way too. But it only works so far..
14:21:52 <sbalukoff> mestery: Yeah, that too. At a certain point the browser starts to crawl...
14:21:54 <jorgem> if people could add relevant links to what you are working on that would be great
14:22:19 <sbalukoff> jorgem: +1
14:22:19 <jorgem> since it is contextual for the timeframe
14:22:24 * rm_work has 124 tabs
14:22:25 <blogan> i think the neutron lbaas wiki needs to be groomed of pages no longer relevant
14:22:35 <german__> +1
14:22:36 <jorgem> blogan: go ahead :)
14:22:37 <mestery> rm_work: 124??????
14:22:49 <rm_work> T_T
14:23:06 <rm_work> I am not good at closing tabs (not all are related to LBaaS :P)
14:23:21 <jorgem> I only have so much RAM though!
14:23:32 <german__> You can save a tab set :-)
14:23:34 <sbalukoff> blogan: That should be safe enough to do: mediawiki should effectively keep an archived old version of the pages that get deleted in case anyone wants to look at them. And having the page gone is beter than having it have the wrong info.
14:24:18 <blogan> sbalukoff: good point
14:24:25 <ptoohill> chrome plugin 'OneTab' is kinda nice too
14:24:39 <blogan> so do we really not have much to talk about lbaas in this meeting then? nothing else to shore up before the hackathon?
14:24:56 <sbalukoff> I personally would like to see all references to Quantum either updated or nuked. :P
14:25:16 <sballe> sbalukoff, I would like to see them updated...
14:25:25 <sbalukoff> blogan: I think we basically covered that in the agenda etherpad that sballe put together.
14:26:05 <jorgem> does anyone have any questions on what people have been working on?
14:26:18 <mlavalle> blogan: where will the api document be posted?
14:26:18 <sballe> Would everybody be ok if I created a Boenyard page and put al the older section on the wiki in there
14:26:19 <jorgem> based on the "standup"?
14:26:22 <blogan> sbalukoff: but are there any items that we haven't come to a consensus on? I can think of one the M:N relationship between loadbalancers and listeners
14:26:30 <sballe> We can deprecate them later once we know they are not needed
14:26:51 <blogan> mlavalle: it will most likely be a google doc at first and may put it on the wiki once thats complete
14:27:13 <mlavalle> thanks
14:27:26 <sballe> blogan, Can you put the link there even before it is completed so we can find it and comment onit?
14:27:33 <sbalukoff> blogan: Lies. This group has no problem agreeing on everything. ;)
14:27:46 <sballe> sbalukoff, +1
14:27:50 <blogan> blogan: a link to the google doc you mean?
14:28:02 <blogan> i just referenced myself
14:28:06 <blogan> im an idiot
14:28:08 <sbalukoff> Yes you did.
14:28:09 <sballe> blogan, tes to the google doc
14:28:12 <sbalukoff> No, it's early.
14:28:20 <german> he is not in PST
14:28:23 * mestery hands blogan some strong coffee.
14:28:24 <blogan> sballe: thanks
14:28:29 <jorgem> mestery: I do have a question related to exposing API functionality, after this topic finishes
14:28:41 <mestery> jorgem: Sure!
14:28:46 * blogan needs somethign stronger
14:28:56 <dougwig> we're nerds.  it's early in any time zone in the US.
14:29:02 <sballe> mestery, jorgem I would liek to be part of that discussion
14:29:16 <sballe> dougwig, +1
14:29:34 <jorgem> My goal is to expose as much API functionality as possible before the code freeze. This means the current ha proxy ref needs to have said functionality correct?
14:29:55 <jorgem> What happens if the current ref can't expose said functionality or other drivers can't?
14:30:02 <mestery> jorgem: That would be ideal. I think dougwig is planning to add that functionality into the current solution.
14:30:21 <mestery> jorgem: We should strive to expose the functionality as much as possible.
14:30:38 <jorgem> mestery: Correct but what if vendor drivers can't?
14:30:55 <jorgem> What happens when that API call is made?
14:31:18 <jorgem> Does a "not supported" get returned to the API user?
14:31:24 <mestery> jorgem: If a vendor driver can't support the API call, they could fail it.
14:31:25 <dougwig> i would expect we should return an unsupported error.
14:31:29 <mestery> dougwig: +1
14:31:32 <german> +1
14:31:40 <sbalukoff> Oh good!
14:31:42 <jorgem> Okay, that leads me to another question...
14:31:44 <ptoohill> dougwig, you are working on updating the ref impl?
14:31:47 <sbalukoff> It's good to hear we can do that.
14:31:49 <samuelbercovici> this is what is expected - unsupurted
14:31:52 <jorgem> Can the ref impl do the same?
14:32:08 <samuelbercovici> jorgem: no in the past
14:32:10 <sbalukoff> Next question: Is it OK to "expose" API functionality even if the reference haproxy implementation can't do it yet?
14:32:18 <vjay4> what is the effect on the drivers? will new driver interfaces be defined
14:32:26 <dougwig> i think someone at rackspace was looking at that, but i'm happy to.  the a10 driver will also implement it all, assuming it gets in.
14:32:29 <samuelbercovici> otherwise the fetures cant be tested
14:32:30 <jorgem> sbalukoff: Yes my question exactly
14:32:43 <sbalukoff> jorgem: Yep!
14:33:01 <ptoohill> Ok, i was just curious. I will be working on the blueprints to it today.
14:33:06 <jorgem> mestery: The reason I am asking these questions is that once the freeze is in place we want to move at 100% on the operator grade impl
14:33:18 <mestery> ptoohill: I may have confused you with dougwig, sorry. I've had a lot of conversations recently :)
14:33:22 <jorgem> but if functionality is not expose then its moot
14:33:25 <vjay4> in case there is a driver which has not made any modifications will be existing  VIP/Pool APIs work fine?
14:33:28 <mestery> jorgem: Agreed!
14:33:43 <jorgem> mestery: So your answer then?
14:33:43 <mestery> jorgem: Yes, agreed. Lets focus on ensuring the existing reference implementation implements as much of the new stuff as possible.
14:33:44 <ptoohill> :)
14:33:44 <german> vjay4 that's the goal
14:33:54 <mestery> jorgem: ^^^ Does that make sense?
14:34:00 <dougwig> ptoohill: let me know if i can help.  i've been wallowing in the driver layer for quite some time now.
14:34:00 <vjay4> german: thanks!
14:34:18 <jorgem> mestery: Is it a blocker it API functionality is exposed but ref impl doesnt implement it per say?
14:34:37 <german> that's like vaporware
14:34:51 <mestery> jorgem: In general, yes, though there is some gray area there. Lets nail it down next week face to face.
14:34:55 <crc32> I agre with sbalukoff we should impement optional features in the API that arn't yet supported by the ref impl.
14:35:00 <sbalukoff> german: It's very opinionated vaporware. :)
14:35:11 <jorgem> mestery: Gotcha just want to make sure we figure that out
14:35:27 <mestery> jorgem: LEts make sure we have that as an item to close on next week face to face.
14:35:30 <jorgem> mestery: Because that can potentially change timelines
14:35:39 <ptoohill> dougwig, after our meeting after this meeting ill probably ping you if youre available to maybe hash this out. I have some ideas to share and would love to hash it out with you
14:36:00 <sballe> crc32, +1
14:36:09 <mestery> jorgem: +1
14:36:18 <dougwig> ptoohill: sounds good..  will you be around at 10am mountain, so i have time to drink coffee and get into the office first?
14:37:03 <ptoohill> I have an hour meeting right after this and will be available right after. So, yes 10am your time should be good for me
14:37:04 <german> jorgem, if we don't get the features in we can still add them to the operator implementation and bring them in early next cycle
14:37:09 <sbalukoff> dougwig: So nice to know I'm not the only one who does these Thursday meetings from bed. XD
14:37:27 <jorgem> german: Yeah thats my concern I don't want to wait :)
14:37:28 <sballe> german, +1
14:37:44 <sbalukoff> german: +1
14:37:56 <jorgem> I know velocity was the main reason we are doing all of this
14:37:57 <sballe> jorgem, I agree that we should be able to have APIs return no-ops if the feature is not supported
14:38:04 <ptoohill> I had questions regarding Stunnel also that i know sbalukoff is familiar with. We can maybe pull him in to if we have questions in that area :)
14:38:13 <rm_work> sbalukoff: I used to but jorgem forced me to make it to the office today. and I hate him now.
14:38:23 <jorgem> rm_work: :)
14:38:32 <sbalukoff> rm_work: Seems justified to me.
14:38:36 <dougwig> rm_work: lol
14:38:37 <ptoohill> sballe jorgem +1
14:38:49 <sbalukoff> rm_work: Make sure to give him the stink eye for the rest of today at least.
14:39:32 <jorgem> We will talk about API functionality next week and also wanted to point out the notion of vendor lock-in. I'll add a topic to the agenda
14:39:46 <sbalukoff> ptoohill: Does that question have to do with SSL session persistence when stunnel + haproxy are being used?
14:39:50 <sballe> jorgem, +1
14:39:52 <ptoohill> :)
14:39:59 <ptoohill> sbalukoff, reading my mind
14:40:28 <ptoohill> 'good luck with that' i take it :P
14:40:48 <sbalukoff> ptoohill: Pretty much. :)
14:41:08 <german> ptoohill, haproxy has a "cluster" mode wouldn't that help
14:41:11 <ptoohill> we have a couple other options like Stud, but considering this is ref impl i wouldnt want to spend too much time trying to decide which to use
14:41:17 <sbalukoff> Though if you can figure out a way to do it, I'll personally have cookies sent to your office.
14:41:18 <dougwig> cookie persistence should work fine.  source ip is the challenge.
14:41:32 <samuelbercovici> ptoohill: sbalukoff: in the TLS proposal we suggest to use different protocols in the listener to differentiate between HTTPS (non terminated) and TLS (terminated) this means that SSL stickiness might not ne needed/allowed for TLS
14:41:56 <ptoohill> that would work out then samuelbercovici
14:41:56 <rm_work> sbalukoff: just don't send us a USB key with a bunch of textfiles
14:42:01 <rm_work> sbalukoff: unless it's a nice one
14:42:12 <sbalukoff> Haha
14:42:29 <dougwig> samuelbercovici: i think that should be a backend decision.
14:43:12 <samuelbercovici> dougwig: does it make sense to do ssl session based stickiness and still terminate?
14:44:09 <dougwig> if you have a cranky old legacy server that has state, but still want ssl offload and such, yes.
14:45:14 <samuelbercovici> fine by me. but this is something that stunnel + haproxy does not support
14:45:44 <dougwig> yeah, that backend will have to throw unsupported.
14:45:57 <samuelbercovici> originaly that idea was to try and standardize the api so that it is harmonized between vendors
14:46:21 <samuelbercovici> such corner cases will make it difficult to do so
14:47:00 <samuelbercovici> but i am perfectly fine with having much open and letting the vendor driver fail if this is not supported
14:47:01 <sbalukoff> samuelbercovici: The more we do that (appealing to the least common denominator) the fewer features we can support overall. It's a tough question because we don't want vendor lock-in, yet we want to be able to take advantage of features that not every vendor can do.
14:47:21 <sbalukoff> samuelbercovici: I agree!
14:47:24 <crc32> +1 sbalukoff
14:47:43 <german> +1
14:47:45 <jorgem> and since we are a plugin right now extensions are kind of out of the question I think
14:47:48 <dougwig> i think it might have to be a case-by-case thing?  the ssl haproxy will probably support this, right?  so it's got obvious future legs.  something more obscure might be different.
14:48:02 <samuelbercovici> sbalukoff: it is fine when you do high level categories of features. ex tls support (yes/no) it becomes problematic if you get quirks in how the feture is supported
14:48:12 <sbalukoff> dougwig: Yep!
14:48:28 <sbalukoff> samuelbercovici: Agreed!
14:48:31 <Julian-Cash> samuelbercovici +1
14:49:08 <sbalukoff> Ok... so we're coming down to 10 minutes left in this meeting. Are there other agenda items?
14:49:29 <blogan> sbalukoff: not on the wiki
14:49:34 * mestery has nothing.
14:49:40 <mestery> Should we call it early?
14:49:49 <sbalukoff> Holy crap, does that mean we actually got through the agenda?
14:49:52 <blogan> mestery: good with me or we can just sit here and not say anything for 10 mins
14:49:54 <Julian-Cash> :-D
14:49:58 <mestery> blogan: :P
14:50:01 <blogan> sbalukoff: easy to get through 2 items
14:50:01 <samuelbercovici> TLS: lloks like the decision whether back-end encryption is supported without server authentiaction or not an all is not clear
14:50:01 * sballe +1
14:50:07 <ptoohill> Ill be in neutron-lbaas to discuss the ref impl changes at roughly 11am cst
14:50:08 <dougwig> 10 minute nap!
14:50:13 <sballe> perfect
14:50:19 <german> bloga, we had two items and used like 60 minutes for item #1 before
14:50:20 <mestery> ptoohill: thanks!
14:50:29 <mestery> Thanks everyone, and we'll see you all next week in San Antonio!
14:50:30 <blogan> german: lol good point
14:50:33 <mestery> Go Spurs! :)
14:50:38 <german> bye
14:50:41 <samuelbercovici> bye
14:50:42 <blogan> mestery: yeah!!!
14:50:42 <ptoohill> :) thank you mestery
14:50:44 <dougwig> bye
14:50:47 <mestery> #endmeeting