13:59:56 #startmeeting neutron lbaas 13:59:56 Meeting started Thu Jul 10 13:59:56 2014 UTC and is due to finish in 60 minutes. The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:59 The meeting name has been set to 'neutron_lbaas' 14:00:05 o/ 14:00:08 yo 14:00:16 hi 14:00:18 o/ 14:00:33 \o/ 14:00:34 (y) 14:00:41 blogan, lol 14:01:10 Anything else people wanted to add to the agenda? 14:01:19 #link https://wiki.openstack.org/wiki/Network/LBaaS#Agenda 14:01:41 there are only 3 items :/ 14:02:16 Morning! 14:02:27 Morning 14:02:28 there are worse things in life than a quick meeting. 14:02:29 :) 14:02:44 Okay well let's start with the first item 14:02:44 +1 14:02:48 #topic Paris summit talks 14:02:55 Susanne? 14:03:18 jorgem, thx. 14:03:19 From the ML I'm not sure if we need to go in real depth on this 14:03:33 but let's get the conversation started at least 14:03:37 I just wanted to make everybody aware of the apporachign deadline of July 28 14:03:53 and wanted to see if we wanted to coordinates talks 14:04:04 morning all 14:04:15 sballe: didnt markmcclain something about design meetigs having a much later deadline? 14:04:20 say 14:04:26 I see several talks taht could be interesting to submit and just wanted to sync-up with you on who wants to do what 14:04:41 hello! 14:04:49 blogan, yes I belive so. I am talking about the talks 14:05:04 sballe: ah okay 14:05:08 * blogan slowly walks away 14:05:28 Call for Speakers Open 14:05:28 Posted: July 4 14:05:28 Would you like to speak at the November OpenStack Summit in Paris? 14:05:28 Submit your talks HERE! 14:05:28 There are several new speaking tracks for the Paris Summit so please review the list of tracks closely before you submit a talk. 14:05:29 Don't wait - the deadline to submit talks is July 28 at 11:59pm CDT. 14:05:45 Fromthe website 14:06:07 you mean the summit talk not the dve summit sessions, right? 14:06:09 link? 14:06:47 i think she just dropped. 14:06:48 samuelbercovici: Yes 14:07:19 so is there a list of proposed subjects? 14:07:24 ok I am back 14:07:38 https://www.openstack.org/summit/openstack-paris-summit-2014/call-for-speakers/ 14:07:50 #link https://www.openstack.org/summit/openstack-paris-summit-2014/call-for-speakers/ 14:07:54 Beat me pasting link by 1 sec. :-) 14:08:29 got me while tabbed out and copying. :) 14:08:30 I am interested in submitting a talk on Octavia and Stephen is interested in being a co-presented. 14:08:56 Octavia, is the HA proxy backend solution, right? 14:09:00 sballe: Sounds good to me? Is the only talk on your mind? 14:09:13 we should submit more. 14:09:26 Octavia is the operator scale LBaaS driver 14:09:28 samuelbercovici: it's effectively an haproxy+servicevm backend. 14:09:30 There are some pretty radical changes in store for Neutron LBaaS this session (or, rather, will hopefully come to fruition by the release). So having a talk on Neutron LBaaS is not a bad idea. 14:09:32 samuelbercovici, ^^ 14:09:46 sbalukoff, I agree 14:09:59 I think that discussing the new lbaas API and roadmap makes also sense 14:10:04 Especially around the Barbican integration 14:10:17 Agreed 14:10:19 samuelbercovici, I agree. 14:10:27 yea too bad we don't have funding. 14:10:45 crc32, You guys are not going? 14:11:01 Even if you get a talk proposal accepted? 14:11:27 I am willing to discuss the TLS / L7, blogan, would you like to discuss core and doug, driver? so we will propose a joint session for the three of us on this... 14:11:31 So…just FYI we, the Rackspace LBaaS team, will most likely not be able to attend in person because of our "budget". We had to pull teeth just to go to Atlanta. We shall see because a lot of Rackers are upset about this. 14:11:49 yea or rather lack of budget. 14:12:08 #embarrassing lol 14:12:29 samuelbercovici: i would love to, but per what jorgem just said, i will probably only be around in etherpad spirit 14:12:29 sbalukoff: crc32: talk proposal accepted gets us free admission, but of course you still have to pay for the trip on your own 14:12:33 Anyways, we would probably need someone to represent our team if we can't find other Rackers to do so. 14:12:46 we got ATC codes already so its free already. 14:12:58 dougwig: will you attend? 14:13:23 yes, i will be there. i'm happy to speak, though i'm an introvert and tend to avoid it like the plague. :) 14:14:14 Okay so I have sballe and sbalukoff marked for a talk on Octavia correct? 14:14:25 yes. here is the list: 14:14:29 Proposed talks: 14:14:30 * Octavia: sballe, sbalukoff 14:14:30 * New LbaaS and roadmaps: 14:14:30 * TLS/L7, Core, driver, samuelbercovici, dougwig, blogan 14:14:30 And for Neutron LBaaS? I'm just trying to take notes 14:14:30 so.. I can for now porpose a tlak on LBaaS new API, what was done for Juno and what are the next steps, I will add anyone willing to this and can always modify the speakers when we get to the date 14:14:43 duly noted 14:15:18 jorgem: don't forget that the foundation has a travel assistance program 14:15:20 samuelbercovici ++ 14:15:40 samuelbercovici, is sounds like topic and 2 and 3 merge into one. right 14:15:43 we need welfare to go to paris 14:15:58 markmcclain: You know if our team used that then maybe our company would get it together on this budget thing. ha! 14:16:06 Proposed talks: 14:16:07 * Octavia: sballe, sbalukoff 14:16:07 * New LbaaS and roadmaps, * TLS/L7, Core, driver, samuelbercovici, dougwig, blogan 14:16:35 I was wanted to talk TLS but what ever. :( 14:16:46 This isn't directly lbaas related and not something that should be chatted about here, but I'll likely propose doing this as a "talk" in Paris if I can be given a room. http://auroralightportraits.com/ 14:17:02 crc32: will you be able to travel? 14:17:15 crc32, please contribute to the talk even if you cannot attend. 14:17:18 I'll have to take out another loan. A big one. 14:17:37 Alright we have a list of topics. Pending travel plans, let's pick speakers later? 14:17:41 the rackspacers need to have a giant bake sale in the empty half of their mall or something. :) 14:17:51 dougwig: thats what i was just saying, and a car wash 14:17:54 dougwig, lol 14:18:02 but please not a topless car wash. 14:18:04 Just sayin' 14:18:05 ;) 14:18:07 Who wants to volunteer to schedule these talks? sballe? 14:18:19 I could dump all my stock. 14:18:21 schedule? 14:18:22 jorgem, yes I can coordinate 14:18:28 awesome thanks 14:18:33 The authors will have to submit them 14:18:54 and I;ll remind them 14:18:56 #action sballe to coordinate setting up talks for Paris summit with authors/speakers 14:19:11 Alright. Next topic 14:19:20 #topic Code Reviews 14:19:22 markmcclain, I will work with you to pick the best categories if necessary 14:19:52 Who wants to kick this off? I know Brandon's 5k line commit got broken into several commits 14:20:06 sballe: sounds good 14:20:09 Also, it is a dependency for other bps 14:20:31 Does anyone have any questions or concerns on this? 14:20:47 Overall I would like to see more comments in the submitted code 14:21:11 i think we need to spin another etherpad with the current list, and just keep reminding people to look (the original has a mid cycle name.) if the feedback cycles get too long, the review time can be weeks. 14:21:17 markmcclain: What is the practice on coments in Neutron? 14:21:25 Yes, we need more people to review (and yes, just back from vacation, so I'll be jumping on that in the next couple days, too.) 14:21:34 dougwig: +1 14:21:49 #action dougwig new review etherpad 14:22:14 johnsom: i got lazy on the commenting in the rush to get this in, and to use a terrible excuse, it wasn't commented any more in the old version 14:22:15 #action dougwig to link review etherpad on Neutron LBaaS wiki page 14:22:19 Is it still the plan for Juno to update remove the v1 LBaaS persistance layer and route it to the v2 persistence layer and plugin 14:22:22 dougwig: ;) 14:22:34 jorgem: comments in code or comments on code? 14:22:39 it -> v1 lbaas API 14:23:07 amusingly, hold off on the current first review right now, as it had a jenkins failure: https://review.openstack.org/#/c/105331/ 14:23:09 dlundquist, I don't think so 14:23:13 markmcclain: I guess both? johnsom what were you thinking of? 14:23:35 dougwig: that failed because of a tempest test failing with floating ips, i think that was just a fluke, i need to make jenkins rerun 14:23:41 markmcclain: I was commenting on the lack of comments in the code 14:23:44 blogan: in that case we will need to merge the two persistence layers at a later point 14:24:33 dlundquist: lets talk about that after the meeting so i understand you fully 14:25:01 johnsom: yeah… ideally the code structure should lend itself to making most comments unnecessary 14:25:17 markmcclain: ++ 14:25:25 +1 14:25:29 ...but not all comments? Please, let's document intent! 14:25:30 generally when I see code and my first thought is that it needs comments, that's probably a sign the structure is wrong 14:25:48 markmcclain where you ever able to review the TLS blueprint https://review.openstack.org/#/c/98640/? 14:25:52 sbalukoff: a bit of intent in the method doc is nice 14:26:01 my philosophy is to comment in code when its not obvious what the code is doing, however with extensions and service plugins it is not obvious how things are getting loaded until you know how the extensions and service plugins work 14:26:02 also well named methods/vars help too 14:26:11 markmcclain: Agreed. 14:26:20 blogan, +1 14:26:24 blogan: yeah we're working to ripe out the ext loading magic 14:26:44 most folks just recite the magic incantation not knowing what it really does 14:26:46 blogan: Also agree. Current codebase makes certain items a little confusing. 14:26:52 jorgem: +! 14:27:09 Yes, providing context for the component is helpful for folks new to the code base 14:27:20 johnsom, +1 14:28:03 So… blogan I guess possibly add comments on codebase that isn't properly decomposed, etc. (not necessarily your fault)? 14:28:32 johnsom: Also could you identify areas in review? 14:28:52 markmcclain: we need your review on https://review.openstack.org/#/c/98640/ 14:28:59 jorgem: comments are kind of a holy war, and what is too many to some is too few to others. i'm not sure there's a concrete action to be had there. 14:29:00 johnsom: i have a feeling you're confusion, along with everyone else's, is the magical extension loading 14:29:20 *your 14:29:29 Yes, I will try to point some out as I review 14:29:43 that'd be a good approach 14:29:55 dougwig: I agree, perhaps have johnsom and blogan sync up in IRC when johnsom is reviewing then :/ 14:30:08 samuelbercovici: yes that is in my queue (I am at the mid-cycle sprint this week) 14:30:54 #action Need markmcclain to review https://review.openstack.org/#/c/98640/ 14:31:00 dougwig: blogan: whats you emails? I am loggin us to a talk as we IRC... 14:31:16 dougw at a10networks.com 14:31:28 main point is getting the refactor reviews in. I may have made assumptions that we did not agree on so look over it carefully and let me know 14:31:40 samuelbercovici: brandon.logan@rackspace.com 14:31:42 o/ uber late :D 14:31:47 #action Need markmcclain to review https://review.openstack.org/#/c/100931/ 14:32:07 blogan: I noticed a couple of those already. But so far they weren't egregious enough for me to -1 stuff. :) 14:32:09 * markmcclain is collecting lots of actions this morning 14:32:12 markmcclain: Kyle already reviewed these, but we need another core reviewer :) 14:32:26 sbalukoff: you could comment and let me know and there might be a method to my madness 14:32:32 markmcclain: Sorry! Either you or another core reviewer. 14:32:43 markmcclain: But of course we prefer you :) 14:32:49 blogan: Will do. 14:32:53 markmcclain: i think its time for the beach and bourbon 14:32:57 jorgem: it's fine they're on my radar 14:32:59 lol 14:33:04 Haha 14:33:12 lol 14:33:13 blogan: it is.. I'll be in FL next week 14:33:25 blogan needs to feel the joy of double-digit patch sets. bring forth the comment nits! 14:33:29 markmcclain: The main concern is meeting the deadline of the 20th. 14:33:56 markmcclain: Is there anything we can do to help you in this regard? 14:34:12 dougwig: ill feel i will hit the 3 digit threshold 14:34:18 jorgem: I expect we'll get them done on time 14:34:24 Other than assuring you you have our undying gratitude? :D 14:34:26 blogan: it's good to have goals. 14:34:37 markmcclain: Awesome. Thanks for your assurance. 14:35:07 * mestery will poke markmcclain for the next two days. 14:35:20 whoa, whoa, get a room. 14:35:24 haha 14:35:34 dougwig: Naughty naughty. 14:35:43 I see 2 code reviews on the v2 work, https://review.openstack.org/#/c/105607/ and https://review.openstack.org/#/c/105331/. I havent looked closely, but they have the same review commit message text. What is the difference? 14:35:56 * TrevorV dougwig is a little jelly methinks 14:36:22 ok. doung brandon, I have registered us for a talk 14:36:24 vjay: that was me being stupid, i abandoned the 105607 one 14:36:28 vjay: One is abandoned? 14:36:30 opps.. doug 14:37:06 samuelbercovici, Great! 14:37:17 samuelbercovici: ty 14:37:18 Okay, any other review related items? 14:37:27 If not, I'll move on to next topic 14:38:02 #topic Shim vs. Agent Refactor 14:38:14 blogan if you would please. 14:38:52 i sent an email about it yesterday and it was long but the shim is going to take a lot of work and so will the agent refactor, the shim is only temporary the agent refactor is permenant 14:38:52 *the calm before the storm* 14:39:19 i meant to send a longer reply to the ML last night, but got derailed. forgive the splat, but here were my thoughts from the lbaas channel yesterday: i saw it, still percolating a reply. i mean, you're right. but you'll make the transition rather lumpy with horizon. it'll go from one set of vendor drivers working (the old ones), to another set (the new 14:39:19 ones), and i doubt they'll match. add to that the uncertainty of when horizon catches up, and it gets less fun. but the corner cases are madness. fwiw, i had been thinking of just chucking exceptions in the corner cases, and letting the 95% common cases work for the older drivers. 14:39:21 also, the shim doesn't seem like it will work with the agent correctly if the v1 api and v2 api are both live 14:39:30 yikes dougwig 14:39:45 sorry :) 14:40:31 dougwig: so I found out something new last night and its that the agent probably won't work with the shim when v1 and v2 are both active 14:40:55 though ill spend more time on it to see if i can work around it 14:41:15 what drivers use the agent besides haproxy? 14:41:27 blogan: If there's not a way around it, does this imply that agent refactor is the only option if we want both v1 and v2 active? 14:41:30 none that i know of, unless there are some that dont live in the current tree 14:41:44 so maybe we just shim the non-agent drivers? 14:41:46 sbalukoff: well basically a v2 agent 14:41:54 dougwig: yes that was a possibility 14:41:57 blogan: That's what I mean. 14:42:32 sbalukoff: well i mean the v1 agent and v2 agent would both still live, but yes if this can't be worked aroudn then it would need a v2 agent 14:42:46 Aah. Ok. 14:43:26 so if it comes down to doing the agent refactor and shim, then which one is priority? 14:44:01 btw sorry for always having a new issue every week and sort flip flopping on what to do, but a lot of this you just odnt know until you actually dive into the code and test it out 14:44:21 Another alternative is parallel v1 and v2 agents and haproxy drivers 14:44:22 Sounds like the highest priority is to determine whether what you discovered last night is certainly true. 14:44:40 well, the ref implementation is the priority. and if the shim is just for agent-less stuff, i think it gets simpler? (and i should have cycles to help starting next week.) 14:44:41 dlundquist: that is the only way to do it, bc v1 still needs to work with the namespace driver 14:45:21 blogan: so the refactor you talk of is is a parallel implementation 14:45:33 dlundquist: yes 14:45:40 ...which should be cleaner in any case. 14:46:06 dlundquist: well just leaving the v1 agent alone, and create a v2 agent based off the v1 agent but using the v2 object models 14:46:24 I think that parlele v1 and v2 would be the easiest. 14:46:52 blogan: we are going to need to go down that route sooner or later in order to expose new functionality that can not be expressed in the v1 object model 14:46:58 also, I would prefer to get the v2 running in paralel as 1st priority and get the shim layers as 2nd phase if needed 14:47:29 i agree with the parallel, and v2 agent being priority 14:47:29 samuelbercovici: +1 I think that's probably the quickest path to success here, too. 14:47:33 samuelbercovici: I thought that was the priority? 14:47:52 jorgem: Reconfirmed, then. :) 14:47:57 dlundquist: yes i agree 14:48:01 well... that code tryies to already address portions of it and I think it make sense to clean this up 14:48:15 Sounds good to me? 14:48:28 :D 14:48:45 I mean "Sounds good to me!" 14:48:47 so getting clean v2 would be a priority 14:49:02 lol, I'm Ron Burgundy? My bad 14:49:08 ok its settled then 14:49:17 unless there are any other objections? 14:49:37 parallel ++ 14:49:45 usually we wait for you to write a few thousand more lines, then object to yourself. 14:49:51 :) 14:49:56 dougwig: lol 14:50:04 im a walking contradiction 14:50:05 I was rooting for 10k 14:50:21 On the TLS blueprint I want to raise a minor point. If there is nothing else i want to go now. 14:50:34 vjay: By all mean 14:50:35 what? 14:50:35 s 14:50:44 SNI part currently says the backend will look into SCN and SAN, during domain match. I feel the most common use case is to match the domain name against the common name (SCN) field of the certificate 14:50:44 so also getting a new namespace ha proxy driver that runs in paralele to exsiting one instead of trying to fix existing one should be agreed upon, right? 14:51:08 #topic Remaining Items 14:51:32 samuelbercovici: i think it was, yes. 14:51:35 vjay: Yes, wildcard certs are less common than single domain certs. 14:51:40 SubjectCommon name or CommonName from the altSubjectName. We have 3 points of entry. 14:51:53 vjay: But we can't ignore SAN, to. 14:52:09 it is clear that the way different backends treat this is unclear.... 14:52:10 SubjectCN altSubjectDNSname and x509Names in subject altNameExt. 14:52:32 samuelbercovici: exactly, could we mention that in the spec 14:52:42 i though that we kind of tried to 14:53:16 specificaly, any case of over lap and priority beween the fields is backend dependant 14:53:18 we did. We originally wanted to have a host field associated with the TLS container but some one thought it'd be a good idea to extract info from the cert. 14:54:01 what the api supports ia ordered list 14:54:03 i think overlap and priority comes in only when SAN is used. There cannot be 2 certificates attached to the same listener with clashing common names 14:54:11 crc32 is right: One party wanted to go with a priority list instead. 14:54:23 atleast that is my knowledge 14:54:32 vjay: Actually, you can do that. :P 14:54:38 thats what SNI is. multiple certs on the listener 14:54:55 vjay: And they can overlap on names. :P 14:55:13 vjay: Though it is stupid and rare, we do occasionally see this. 14:55:25 vjay, not true, theoreticaly it make sense to have same SAN with for example differen expiration dates 14:55:49 samuelbercovici: Or different key lengths. 14:56:41 I think it may come to not having a concensus on how different backent support such a rare case 14:57:19 We have consensus, even if it's not what many prefer: We went with the priority list. 14:57:33 vjay: Can you start a thread on the ML for your concerns? 14:57:37 We only have 2 mins left 14:57:42 yes 14:57:52 i will start on the ML 14:58:02 #action vjay to start ML thread on TLS blueprint concerns 14:58:04 ok 14:58:08 vjay: thx 14:58:21 Alright, well I think that's it for today then everyone 14:58:31 Thanks, y'all! 14:58:38 later 14:58:38 o/ 14:58:41 bye 14:58:43 If you haven't filled out standup please do when you get a chance! 14:58:53 https://etherpad.openstack.org/p/neutron-lbaas-weekly-standup 14:58:57 bye 14:59:04 see you guys 14:59:09 #endmeeting