14:02:12 #startmeeting neutron lbaas 14:02:13 enikanorov_: The meeting is typically called just lbaas? or neutron_lbaas? 14:02:13 Meeting started Thu May 1 14:02:12 2014 UTC and is due to finish in 60 minutes. The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:16 Heh 14:02:17 :) 14:02:17 The meeting name has been set to 'neutron_lbaas' 14:02:27 #link https://wiki.openstack.org/wiki/Network/LBaaS Agenda 14:02:41 So, thanks to all for joining and thanks for the great discussions on the ML! 14:02:57 One thing I was hoping was that today we could try to keep focused on a single conversation at a time. 14:03:09 I've noticed in the past few weeks it's hard to keep up with everything during this meeting. 14:03:26 There is a lot to cover for sure, but trying to focus on one conversation at a time makes it easier. Sound ok? 14:03:37 sounds good 14:03:37 sure 14:03:39 Ok! 14:03:41 agred 14:03:43 agreed*** 14:03:44 rgr 14:03:46 Great! 14:03:51 hello 14:03:54 we'll try 14:03:57 :) 14:03:59 rm_work: :) 14:04:28 OK, so to start off per enikanorov_'s email, lets talk about sbalukoff's google doc a bit more 14:04:31 #link https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit#heading=h.hgpfh6kl7j7a 14:04:33 sure 14:05:13 sbalukoff: I've read through this, thanks for putting this together! 14:05:28 Glad I could help! 14:05:35 Actually, I see a lot more recent comments on this since I read through it a few days back even :) 14:06:10 sbalukoff enikanorov_: The main focus in this document is the API, correct? Have people had a chance to look at this in detail yet? 14:06:34 i've looked at it and asked some questions about it to stephen on the ML 14:06:39 yes 14:06:50 Yes, my understanding was this was an API design proposal, and we've attached a proposed object diagram to it, too. 14:06:51 mestery: I have looked at it and sent comments on L7 to ML and will send later today comments on SSL. 14:07:00 stephen did answer them and most of them were minor quibbles 14:07:30 OK, great! Are people converging on this being at least a good starting point from the LBaaS API perspective? 14:08:08 mestery: I sent an email last and think that all proposals should be compared on equal footing. 14:08:16 more particularly, a question to Rackspace folks: do you find 'single call' part of the document suitable for your needs? 14:08:25 I would also like to know at some point (not necessarily during this meeting): What requirements / use cases or other concerns that you have might not be addressed in thie proposal? 14:08:27 jorgem: Yes, completely agree there. 14:08:28 blogan: did not see response on [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs 14:08:34 yes -- funnily enough, it actually seems remarkably similar to what we proposed :) I think I am ok with most of it, besides a few naming issues and minor attributes 14:08:40 I'd like to discuss the pros and cons of each proposal. So far I see three. 14:08:51 though yes, we should go through all of them 14:09:14 +1 14:09:24 There are things I do like about this proposal but I want to make sure we get the good ideas from all of them. 14:09:27 samuelbercovici: it was the day stephen put it on the ML, wasn't in response to that thread 14:09:29 jorgem: I am fine with that, I think we should ideally try to converge by next week so we can make effective use of the Summit facetime. Agree? 14:09:41 mestery: agree 14:09:47 i think naming differences and attributes polishing is what could be done on per-feature basis 14:10:00 enikanorov_: sure, which is why i have no real stated objections 14:10:07 rm_work: good! 14:10:17 though I don't speak for my whole team, obviously 14:10:18 OK, so now hte question is: How should we effectively evaluate all 3 proposals in the coming week? 14:10:41 One of the the important things I do not want to lose sight of is building the API against the features that we have prioritized. Edge cases shouldn't be a show stopper. 14:10:46 We need someone to come up with a good comparison of all 3, showing gaps and overlap, etc. 14:11:00 jorgem: I agree with that sentiment. 14:11:15 though sbalukoff I am not seeing SSL Termination support? or am I just blind… 14:11:20 one moment, guys 14:11:24 there are TWO proposals 14:11:26 not three 14:11:36 enikanorov_: sbalukoff's, yours, ours? 14:11:37 rm_work: It's in there, with SNI support, too. 14:11:44 yeah it is 14:11:46 mine is a part of stephen's 14:11:47 enikanorov_: I though you wanted to start from the current API? 14:11:51 SSL support is a concern for the VPN folks, too, so there is some overlap... 14:11:53 sbalukoff: I saw the SNI but not how exactly we'd terminate. i'll look again 14:12:08 jorgem: stephen's proposal can be implemented by evolving existing API 14:12:26 rm_work: Look at the default_certificate_id attribute of the "listener" object. :) 14:12:38 enikanorov_: Okay, two proposals then. My apologies. 14:12:43 jorgem enikanorov_: If this is the case, then we can quickly find gaps between the two proposals and try to close them to satisfy the use cases I think. 14:12:43 np 14:13:01 sbalukoff, since SSL overlaps it should be outside VPN, LBaaS 14:13:02 i see one major gap 14:13:09 sbalukoff: so… just by specifying that, it terminates? 14:13:12 which is API nesting in jorgem's proposal 14:13:16 mestery: So to answer your question. I think we should have workflows of single and multiple api calls for each of the use cases we have identified. 14:13:17 vs flat API in sbalukoff's 14:13:27 mestery: Do you want someone to just create a spreadsheet with proposals as the columns, and use cases as the rows? 14:13:30 jorgem: I agree with that, per the email thread. 14:13:31 one conversation por favor 14:13:37 enikanorov_: sbalukoff claimed everything could be nested, did he not? 14:13:39 sbalukoff: That would be awesome! 14:13:54 i think the main difference is the use of the term load balancer (which obviously can be changed) and rackspace's proposal support multiple vips but only one port on a single "load balancer" instance while stephen's support an IPv4 and IPv6 VIP and multiple ports on the "load balancer" instance which he calls a VIP 14:13:57 rm_work: i mean nesting in url structure, not in the payload 14:14:00 rm_work: I think I did, or effectively did. 14:14:03 Folks, lets focus on the API comparison now, can we leave the SSL stuff to a bit later? 14:14:08 enikanorov_: ah, thanks for the clarification 14:14:18 I know that's important, but we need to focus on one thing or it gets too hard to maintain a semblence of order. :) 14:14:31 yes, i think we need to discuss SSL separately 14:14:32 mestery +1 14:14:39 mestery: sorry, will try HARDER. :) 14:14:44 Lets finish the API talk and then move on to SSL next. 14:14:52 blogan: you see it's structurally the same 14:14:57 mestery +1 14:15:18 sbalukoff: So, are you volunteering to produce the API comparision spreadsheet mapping to use cases? CAn you work with jorgem on this? 14:15:35 mestery: i will help out as well 14:15:42 mestery: Yes I will help 14:15:44 blogan: Perfect! 14:15:53 good 14:15:54 can we share the spreadhseet so we all can pitch in 14:15:54 I will assign the three of you an action item for that. 14:16:01 mestery: i will help out as well 14:16:03 mestery: Sure! I'm sensing an action item? 14:16:08 german_: of course 14:16:11 german_: Absolutely! I think it makes sense to have someone start it off and then share it. 14:16:22 sbalukoff: Have you had a chance to look at the workflows we presented. I think if you could create something similar it may help to identify pros and cons. 14:16:24 #link https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0 14:16:24 great!! 14:16:29 #action sbalukoff jorgem blogan to draft API comparison spreadsheet mapping to use cases. 14:16:36 blogan: Could you (or someone one your team) please produce a glossary of terms for your API proposal? Just so we are all clear on definitions. 14:16:45 sbalukoff: If you have another idea I am open to that as well. 14:16:46 sbalukoff: sure 14:17:10 jorgem: I looked through a couple of them (I think you had 9 at the time)? 14:17:17 #action blogan creates glossary of terms for rackspace's proposal 14:17:18 correct. we will add more 14:17:19 So the expectation is by next week's IRC meeting (ideally before) we can have this ready and ideally make a decision to move forward then. 14:17:28 I don't know that I can address all use cases, since the use case document is up to 43 so far. 14:17:34 And that's just the "user" use cases. 14:17:48 jorgem: Thanks for hte link, nice work on drafting all of that up! 14:17:58 sbalukoff: That's fine the main ones that hit on the feautures we have prioritized should be a good place to start. 14:18:00 some of the use cases map to particular set of values for attributes 14:18:04 sbalukoff: I've been doing some work with examples according to our API, not sure if you'd like me to share those in this comparison chart as well 14:18:13 like 'support for XXX balancing algorithm' 14:18:25 sbalukoff: Specifically with use cases I mean 14:18:25 By the way-- I want to be clear that my proposal certainly isn't "set in stone". If we discover gaps, I'm hoping to change the proposal to address the gaps. 14:18:45 i think that we need to have a general consensus on the API 14:18:49 sbalukoff: understood. Likewise for ours. 14:18:50 and then flush details 14:18:51 TrevorV: It sounds like that might be useful, eh! 14:18:55 like attributes and such 14:19:07 sbalukoff: same with rackspace, that was always the intention 14:19:16 Cool. 14:19:18 otherwise we'll gid in the details without producing a decision 14:19:49 *dig 14:19:53 I think we have a plan on the API front here to move forward, comparing and closing gaps. 14:20:07 sbalukoff: Let's decide first which use cases to produce workflows so we can make sure we compare the same use cases. What do you think? 14:21:05 Can we move on to the SSL discussion now? 14:21:15 Seems like there was some interest in talking about that a bit. 14:21:20 i have a question about the object model 14:21:23 jorgem: That sounds fine to me, mostly... though I'm honestly a little uncomfortable potentially leaving some use cases out. 14:21:23 just a quick question 14:21:29 blogan: Sure, go ahead please. 14:21:42 sbalukoff: I'm okay with doing all or a subset. It's your call. 14:21:47 what happens if the API that is decided on requires a major revamp of the object model? 14:22:15 jorgem: Shall we talk about this offline? (Don't think we need to take up meeting time for that level of specificity, eh.) 14:22:15 how major are you expecting it to be? 14:22:27 sbalukoff: Yes, I'll send you an email. 14:22:39 Cool, thanks! 14:22:41 oh I don't know, its more a theoretical question, I'm just wondering how major revamps work in this type of project 14:22:46 every proposal changes object model in some way 14:23:08 blogan: so far proposals are focused around the same set of objects 14:23:28 Should we expect at least minor object model changes here? jorgem sbalukoff enikanorov_?? 14:23:32 it's better to do anychanges in the way that existing code (even if changed) still works 14:23:33 what are the aspects in which comparision will be done? like backward compatibil 14:23:38 mestery: absolutely 14:23:45 mestery: I think so. 14:23:47 But... 14:23:48 reuse 14:24:06 Stated another way, I think: Are there any potential changes that are off the table? 14:24:18 object model changes in several aspects: attributes, relationships and object being added 14:24:29 mestery: There will definitely be additions since there are new features being requested. 14:24:36 i think both proposals imply that 14:24:43 well i'm just afraid that if we try to duct tape the API around an object model that doesn't work well with the API then it will be a maintenance nightmare, thats my real concern 14:24:45 sbalukoff: I am an evolutionary guy, so if we can evolve the current model into something new, it's better, but lets see what we come up with. 14:24:52 jorgem: Agreed there. 14:25:07 blogan: obj model is changed with API obviously 14:25:10 blogan: Lets cross that bridge when we get there and make a call as a team at that point. 14:25:16 mestery: evolution is fine from a good foundation 14:25:29 I think we should agree on API spec first. Then figure out a transition plan. 14:25:32 blogan: the foundation is good enough, actually 14:25:38 jorgem +1 14:25:41 jorgem: +1 14:25:47 jorgem: +1 14:25:51 yes, that would be the right thing to do 14:25:59 jorgem: +1 14:26:00 Perfect! 14:26:04 yea like evolution works but some APIs have to go extinct for this to work. 14:26:04 +1 14:26:10 OK, anything else on the API front now? 14:26:23 jorgem: +1 14:26:25 I think we have a good plan for the next week to address this. 14:26:32 should we discussion on what aspects to be considered during comparison? 14:26:42 my questions about SSL are specific to sbalukoff's API proposal, so does that count for API discussion or SSL discussion? :) 14:26:42 And we should definitely continue the ML discussions on the API Front once the comparison spreadsheet is done. 14:26:44 sorry discuss 14:26:53 no im good 14:27:06 rm_work: Lets answer vjay's question then go to SSL :) 14:27:11 vjay: I think that is a good idea. What metrics to compare on? 14:27:29 before we go into SSL 14:27:32 vjay: I think our plan was to compare / contrast workflows for specific use cases, and present this in a spreadsheet. 14:27:32 vjay: I think we're covering all use cases and mapping APIs to the use cases, right jorgem sbalukoff? 14:27:49 mestery: Yes. 14:28:05 vjay: Does that answer your question? 14:28:08 I think that probably the first 8 use cases should be fine to see how workflows would differ 14:28:12 vjay: So, if yo have a specific use case that's not yet addressed in the document, get it in there ASAP! 14:28:21 ok. 14:28:32 thats fine 14:28:39 OK, lets move on to SSL. 14:28:44 rm_work: The floor is yours. :) 14:28:51 yes, many of those use cases are really "duplicate" with regard to actual workflow, since they just specify like "do what we just did, but with a different protocol", etvc 14:28:53 *etc 14:29:13 mestery: heh, well I don't have MUCH, just trying to understand how SSL Term works in sbalukoff's proposal 14:29:33 sbalukoff: I think I may get it now -- so to do SSL Term, you use HTTPS protocol, and HTTPS passthrough would use TCP? 14:29:57 I was just expecting HTTPS to be "passthrough" and there to be a specific option to enable SSL Term, since that is what I am used to seeing 14:30:39 rm_work: Yes. Though I didn't specifically address the case of doing session tracking using SSL session_id in this-- that could be done with additions to the Layer-7 stuff, or an explicit flag that states whether HTTPS connections should be terminated on the load balancer. 14:31:23 rm_work: That specific option could be added. 14:31:27 yeah, ok 14:31:38 I might worry it would be confusing when not explicit :) 14:31:42 One of the goals of my API was to try to keep the number of object and number of attributes per object minimal. 14:31:44 SSL session_id is usualy a persistency property for HTTPS 14:31:53 Since there's a maintenance cost going forward for having them. 14:32:15 sbalukoff: that is a good goal to have 14:32:17 samuelbercovici: Yep. 14:32:37 that's all I had :) like I said, just wanted to clear that up 14:32:40 blogan: There are other implications like that subtly hidden in my API proposal. 14:32:41 so we could have had HTTPS for non teminated protocols and TLS for terminated ones 14:33:16 samuelbercovici: so that the protocol more clearly implies what's happening with regard to termination? 14:33:26 samuelbercovici: Yep! It's just a matter of specifing the exact parameter, and what the load balancer behavior should be for each parameter. 14:33:37 this is a good things as there are capabilities available for TLS which should not be available for HTTPS 14:33:52 I would be for that, though I worry about the redundancy of having another protocol just to explicitly state "this is HTTPS Passthrough" when it's exactly the same functionally as TCP :( 14:34:08 +1 14:34:31 rm_work: this is not exactly the case as for exmaple SSL session id is only relevant for HTTPS and not TCP 14:34:37 ah, true 14:34:43 rm_work: Would it make sense to list the protocols we want to support and how they should be treated on the load balancer? 14:34:56 yes 14:35:02 actualy TLS has all the capabilitiy of HTTP 14:35:10 from a configuration perspective 14:35:13 SSL session id is apart of the TLS handshake so it could be used on TCP as well right? 14:35:19 sbalukoff: maybe? normally I would say that's outside the realm of an API spec, but in this case they have specific implications about API functionality 14:35:47 rm_work: The devil is always in the details. :) 14:35:56 crc32: but if it is a pure TCP protocol it should not be avialble for selection 14:36:02 from an end-user of the api having a specific call out for termination would be best 14:36:09 less abiguity 14:36:29 i agree 14:36:34 Well, if the protocols were more clear in specifying that they were controlling SSLTerm/Passthrough, it would be fine I think 14:36:35 Well, there's also the question: Is there a use case we're considering that uses TLS that *is not* just HTTPS? 14:36:36 think of least common denominator (customers) 14:36:44 as it is, it was ambiguous enough to cause me confusion 14:36:49 ie. some other protocol support that's also using transport layer security? 14:36:56 If so, can we get that added to the use cases? 14:37:28 HTTP / HTTPS (Terminated) / HTTPS (Passthrough) / TCP 14:37:38 sbalukoff: obviously HTTPS on a non default 443 port does not meet your case, right? 14:38:43 sbalukoff: in your proposal there is a difference between SNI and a siongle certificate, why is this? 14:39:03 but anyway, that is pretty much my only gripe currently with this proposal (other than I'd rather have Loadbalancer as the root object instead of VIP, though I see that you're trying to use an LB object for something specific at a higher level...) 14:39:08 samuelbercovici: Actually HTTPS on a non-standard port is still HTTPS, in my opinion. 14:39:14 sbalukoff: I can't think of one but tls does appear specified outside of the protocol. So do we lock TLS into HTTP(ssl term) and HTTPS(passthrough with SSLID persistence) only and regret it later on? 14:39:16 Covered under the same use case. 14:39:22 sbalukoff +1 14:39:28 balukoff: yes i agree 14:39:33 sbalukoff: there are a great many SSL termination use-cases in the document. Some of which I have addressed with the Rackspace proposal already, we can see those when we compare the APIs if you like 14:39:43 samuelbercovici: and I think it is because there should be a default cert for fallback if no SNI matches? 14:40:01 crc32: Until someone has a use case we want to address, yes. In this case, I don't like leaving things too open-ended or you end up trying to solve problems that are never actually problems. 14:40:19 oh wait, i might be reading the wrong section 14:40:30 So on the SNI stuff: 14:40:41 rm_work: I think that might be addressed by ordering the list 14:40:49 fair enough. I just wonder if any one wants LDAPS to session persisted. 14:40:56 Yes, the default cert id attribute of the listener covers cases of HTTP/1.0 connections, or where SNI is not being used. 14:41:42 It turns out, even with SNI, you still need to specify the default cert, in case the web client asks for a hostname that's not explicitly configured. 14:41:42 samuelbercovici: yeah, i would assume the default cert id would be used if there are no SNI rules specified, as opposed to requiring an SNI rule on every SSL LB, and using * as a match 14:42:34 If you're just going to be using one certificate for a given HTTPS site, then you don't have to worry about SNI policies at all. 14:42:41 Just specify the default_certificate_id. 14:43:14 But if you want to use more than one certificate for a listener (ie. this is an IP + single port combination), then the only way to do this is with SNI. 14:43:15 default certificate must be provided in case SNI is not supported 14:43:30 samuelbercovici: Correct. 14:43:49 but it can be the 1st in the list 14:43:50 Though, with very few exceptions, all modern browsers can do SNI. 14:43:58 if no SNI, than only one certificate 14:44:06 Yes. 14:44:23 That works too... 14:44:23 so why are there two diferent entries? 14:44:34 samuelbercovici: but then you require the user to set up "SNI Cert" with some match, even if they don't know what SNI *is*? :P 14:44:43 I was trying to do the same kind of model that works for default pool vs. pool that gets selected for L7 policy. 14:44:54 Er... pool that gets selected by an L7 policy. 14:45:29 rm_work: If the user wants to use more than one certificate per HTTPS listener, they need to understand they're using SNI. 14:45:36 As it is, though... 14:45:40 but if they don't want more than one.... 14:45:41 the other part is that I prefer to specify trusted certificates using the same scemantics on a differetn list 14:45:54 they shouldn't have to set up SNI, which they would if we removed the "default cert" concept 14:46:04 rm_work: Aah! Yes, you're right. 14:46:27 this might be more easier than to ustilize if certificates are actualy stores in Barbican 14:46:53 Yeah, I have no problem splitting trusted_certificates away as its own object instead of using the ca_chain field of the tls_certificates objects. 14:47:03 The way I suggested uses fewer objects but is certainly more confusing. 14:47:07 how would that work for an off-the-shelf LB on the backend? 14:47:47 tmc3inphilly: Sorry, I'm not sure who you're asking, and that "that" is in your question. 14:47:59 and what "that" is. 14:48:04 Sheesh. Sorry, guys, it's early. 14:48:12 sorry the management of certs through Barbican 14:48:17 I am also missing the capability to controll allowed protocols (ex: TLS1, TLS.1.2) and allowed cypher suites both for temination an backencryption 14:48:25 I assume it would be "transparently" 14:48:48 samuelbercovici: I am not sure allowing control of cipher suites is a great idea in general <_< 14:49:03 you should be able to specify protocols (force TLS 1.2) 14:49:04 I guess if it is an absolute requirement for some... 14:49:12 tmc3inphilly: Oh! Well... I need to look into how to use barbican first of all. But presumably it'd would be treated simply as an SSL certificate store. So you could potentially still add and removed certificates using LBaaS API, they just won't be stored by us. 14:49:42 sbalukoff gotcha 14:49:47 sbalukoff: yes, this is how it shoould be treated 14:49:49 sbalukoff: yeah, that's what I am thinking. it's essentially transparent. we take in the cert -> throw it in barbican -> store the barbican ID 14:49:59 done 14:50:00 samuelbercovici: Yes, I didn't address SSL ciper and protocol support. I think I would just make these additional attributes of the listener. 14:50:09 rm_work: +1 to that 14:50:36 sbalukoff I was advocating useing barbican to store the keys only (Since encrypting the keys was the end goal) and not for storing the X509s as well. 14:50:41 sbalukoff: ok. the one I have in addition 14:50:50 samuelbercovici: I don't see a real need to control ciphers and protocol information per certificate. (I'm not even sure that's possible.) 14:51:05 how about cipher suite profile? 14:51:05 there is some question about HOW we store it in barbican (on the tenant? on our own service account? if it's on the tenant, what happens if they mess with it outside of our API?) but that discussion can happen later 14:51:05 sbalukoff' 14:51:08 sbalukoff: you are right 14:51:09 crc32: It could be done that way, too, yes. 14:51:40 pre-defined cipher suite profiles 14:51:46 folks, i suggest we switch to the summit agenda 14:51:46 rm_work: Yes, it would be on the tenant, and presumably that would break things for us if they do mess with it outside our API. 14:51:47 sbalukoff: No I think the attempt was to store the CIPHER suit at the loadbalancer layer. 14:51:52 we have 10 minutes left 14:52:07 10 minutes left, yes. :) 14:52:11 Actually now 8 14:52:17 sbalukoff: it should be on the tenant 14:52:23 and we can't run over :-) 14:52:23 Ok, further SSL questions on the mailing list! 14:52:33 sbalukoff: +1! 14:52:38 +1 14:52:47 OK, so, Summit Agenda. 14:53:00 LBaaS has 2 40 minute slots, there is a lot to cover and we want to make good use of those slots. 14:53:13 i think there should be 2 general discussions 14:53:23 concluding the API decision would be top 14:53:25 which are user requirements and operator rquirements 14:53:48 We may want to leave some time in one session for the key/certificate discussion with Barbican as well, just a thought. Maybe 15-20 minutes of one of those. 14:53:58 right 14:54:02 to me the goal form the summit is to have action items, tasks and prople allocated so work could start 14:54:13 i also think that's not necessary to devide those two in 1:1 ratio 14:54:16 samuelbercovici: +1 14:54:36 mestery: I think we can discuss 1st with VPNaaS and Barbican on ML 14:54:37 Yes, we should be prepared to discuss open items which have not closed prior to the summit, and come out of it with a plan to move forward. 14:54:49 also, there's an idea to hold additional face to face discussion out of design tracks. i'll probably will have a room to host this 14:54:54 samuelbercovici: Yes, in fact we discussed in the advanced services meeting yesterday. 14:54:55 what do you think on this? 14:55:09 Once an API proposal is selected (to start from). We need to figure out a transition plan in terms of implementation. Should that be a part of the general meetings or held in more of the design sessions? 14:55:20 enikanorov_: That's good, we need to make sure we send invites on ML so people know where it is, times, etc. 14:55:28 mestery: sure! 14:55:45 jorgem: I think we should proceed on ML for that one and hope to close before the summit. 14:55:50 enikanorov_: gr8 14:56:07 mestery: Close on API, transition plan or both? 14:56:10 One thing that we will need to do is discuss either the reworking of the current haproxy driver, or the creation of a new opensource driver for the HA / Scalability / Operator Requirements concerns. We've left this on the backburner because of the (correct) focus on the API, but it might at least be worth mentioning. I suppose we could probably un-conference that discussion though. 14:56:45 mestery: if from some reason this is not done by th summit. than it must be done in the summit in whatever manner otherwise we can progress anywhere 14:56:49 rm_work: that's interesting 14:56:54 rm_work: My team is already engaged in the latter, though we've not made much progress as I've been rather distracted with API discussion lately. :) 14:57:03 rm_work: can you send me an email with your thoughts on this? 14:57:05 sbalukoff: yeah, I assume this will be a group effort 14:57:15 Yep. 14:57:20 rm_work: +1 14:57:21 yep 14:57:24 enikanorov_: I'll try to work something up today. Just you, or just throw it up on the ML? 14:57:31 jorgem: API, sorry. :)_ 14:57:37 ML would be fine rm_work. 14:57:38 yeah, ML is even better 14:57:38 ML, please 14:57:42 kk 14:57:45 samuelbercovici: Agreed 14:58:28 OK, we're about out of time. 14:58:33 Lets wrap this one up now. 14:58:33 ok, so we'll have another meeting before the summit 14:58:39 We have some good action items! 14:58:43 yeah 14:59:03 gr8 stuff!!! 14:59:09 Alright, thanks everyone! 14:59:11 Yay! 14:59:12 ah I suppose... 14:59:22 #action rm_work Start driver discussion on ML 14:59:36 Thanks everyone, we'll see you all in-channel or on the ML! 14:59:51 bye 14:59:54 thanks, bye 14:59:55 see you, bye 14:59:57 bye 15:00:02 thanks! 15:00:05 thanks! 15:00:09 ciao 15:01:10 enikanorov_: Did you do #endmeeting? 15:01:17 Nope. 15:01:20 not yet 15:01:23 K 15:01:23 #endmeeting