14:02:12 <enikanorov_> #startmeeting neutron lbaas
14:02:13 <mestery> enikanorov_: The meeting is typically called just lbaas? or neutron_lbaas?
14:02:13 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:16 <mestery> Heh
14:02:17 <mestery> :)
14:02:17 <openstack> The meeting name has been set to 'neutron_lbaas'
14:02:27 <mestery> #link https://wiki.openstack.org/wiki/Network/LBaaS Agenda
14:02:41 <mestery> So, thanks to all for joining and thanks for the great discussions on the ML!
14:02:57 <mestery> One thing I was hoping was that today we could try to keep focused on a single conversation at a time.
14:03:09 <mestery> I've noticed in the past few weeks it's hard to keep up with everything during this meeting.
14:03:26 <mestery> 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 <blogan> sounds good
14:03:37 <enikanorov_> sure
14:03:39 <sbalukoff> Ok!
14:03:41 <TrevorV> agred
14:03:43 <TrevorV> agreed***
14:03:44 <tmc3inphilly> rgr
14:03:46 <mestery> Great!
14:03:51 <jorgem> hello
14:03:54 <rm_work> we'll try
14:03:57 <mestery> :)
14:03:59 <mestery> rm_work: :)
14:04:28 <mestery> OK, so to start off per enikanorov_'s email, lets talk about sbalukoff's google doc a bit more
14:04:31 <mestery> #link https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit#heading=h.hgpfh6kl7j7a
14:04:33 <samuelbercovici> sure
14:05:13 <mestery> sbalukoff: I've read through this, thanks for putting this together!
14:05:28 <sbalukoff> Glad I could help!
14:05:35 <mestery> Actually, I see a lot more recent comments on this since I read through it a few days back even :)
14:06:10 <mestery> 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 <blogan> i've looked at it and asked some questions about it to stephen on the ML
14:06:39 <jorgem> yes
14:06:50 <sbalukoff> Yes, my understanding was this was an API design proposal, and we've attached a proposed object diagram to it, too.
14:06:51 <samuelbercovici> mestery: I have looked at it and sent comments on L7 to ML and will send later today comments on SSL.
14:07:00 <blogan> stephen did answer them and most of them were minor quibbles
14:07:30 <mestery> OK, great! Are people converging on this being at least a good starting point from the LBaaS API perspective?
14:08:08 <jorgem> mestery: I sent an email last and think that all proposals should be compared on equal footing.
14:08:16 <enikanorov_> more particularly, a question to Rackspace folks: do you find 'single call' part of the document suitable for your needs?
14:08:25 <sbalukoff> 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 <mestery> jorgem: Yes, completely agree there.
14:08:28 <samuelbercovici> blogan: did not see response on [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
14:08:34 <rm_work> 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 <jorgem> I'd like to discuss the pros and cons of each proposal. So far I see three.
14:08:51 <rm_work> though yes, we should go through all of them
14:09:14 <german_> +1
14:09:24 <jorgem> 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 <blogan> samuelbercovici: it was the day stephen put it on the ML, wasn't in response to that thread
14:09:29 <mestery> 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 <jorgem> mestery: agree
14:09:47 <enikanorov_> i think naming differences and attributes polishing is what could be done on per-feature basis
14:10:00 <rm_work> enikanorov_: sure, which is why i have no real stated objections
14:10:07 <enikanorov_> rm_work: good!
14:10:17 <rm_work> though I don't speak for my whole team, obviously
14:10:18 <mestery> OK, so now hte question is: How should we effectively evaluate all 3 proposals in the coming week?
14:10:41 <jorgem> 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 <mestery> We need someone to come up with a good comparison of all 3, showing gaps and overlap, etc.
14:11:00 <mestery> jorgem: I agree with that sentiment.
14:11:15 <rm_work> though sbalukoff I am not seeing SSL Termination support? or am I just blind…
14:11:20 <enikanorov_> one moment, guys
14:11:24 <enikanorov_> there are TWO proposals
14:11:26 <enikanorov_> not three
14:11:36 <rm_work> enikanorov_: sbalukoff's, yours, ours?
14:11:37 <sbalukoff> rm_work: It's in there, with SNI support, too.
14:11:44 <blogan> yeah it is
14:11:46 <enikanorov_> mine is a part of stephen's
14:11:47 <jorgem> enikanorov_: I though you wanted to start from the current API?
14:11:51 <german_> SSL support is a concern for the VPN folks, too, so there is some overlap...
14:11:53 <rm_work> sbalukoff: I saw the SNI but not how exactly we'd terminate. i'll look again
14:12:08 <enikanorov_> jorgem: stephen's proposal can be implemented by evolving existing API
14:12:26 <sbalukoff> rm_work: Look at the default_certificate_id attribute of the "listener" object. :)
14:12:38 <jorgem> enikanorov_: Okay, two proposals then. My apologies.
14:12:43 <mestery> 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 <enikanorov_> np
14:13:01 <german_> sbalukoff, since SSL overlaps it should be outside VPN, LBaaS
14:13:02 <enikanorov_> i see one major gap
14:13:09 <rm_work> sbalukoff: so… just by specifying that, it terminates?
14:13:12 <enikanorov_> which is API nesting in jorgem's proposal
14:13:16 <jorgem> 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 <enikanorov_> vs flat API in sbalukoff's
14:13:27 <sbalukoff> mestery: Do you want someone to just create a spreadsheet with proposals as the columns, and use cases as the rows?
14:13:30 <mestery> jorgem: I agree with that, per the email thread.
14:13:31 <tmc3inphilly> one conversation por favor
14:13:37 <rm_work> enikanorov_: sbalukoff claimed everything could be nested, did he not?
14:13:39 <mestery> sbalukoff: That would be awesome!
14:13:54 <blogan> 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 <enikanorov_> rm_work: i mean nesting in url structure, not in the payload
14:14:00 <sbalukoff> rm_work: I think I did, or effectively did.
14:14:03 <mestery> Folks, lets focus on the API comparison now, can we leave the SSL stuff to a bit later?
14:14:08 <rm_work> enikanorov_: ah, thanks for the clarification
14:14:18 <mestery> 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 <enikanorov_> yes, i think we need to discuss SSL separately
14:14:32 <german_> mestery +1
14:14:39 <rm_work> mestery: sorry, will try HARDER. :)
14:14:44 <mestery> Lets finish the API talk and then move on to SSL next.
14:14:52 <enikanorov_> blogan: you see it's structurally the same
14:14:57 <samuelbercovici> mestery +1
14:15:18 <mestery> 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 <blogan> mestery: i will help out as well
14:15:42 <jorgem> mestery: Yes I will help
14:15:44 <mestery> blogan: Perfect!
14:15:53 <enikanorov_> good
14:15:54 <german_> can we share the spreadhseet so we all can pitch in
14:15:54 <mestery> I will assign the three of you an action item for that.
14:16:01 <samuelbercovici> mestery: i will help out as well
14:16:03 <sbalukoff> mestery: Sure! I'm sensing an action item?
14:16:08 <blogan> german_: of course
14:16:11 <mestery> german_: Absolutely! I think it makes sense to have someone start it off and then share it.
14:16:22 <jorgem> 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 <jorgem> #link https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0
14:16:24 <german_> great!!
14:16:29 <mestery> #action sbalukoff jorgem blogan to draft API comparison spreadsheet mapping to use cases.
14:16:36 <sbalukoff> 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 <jorgem> sbalukoff: If you have another idea I am open to that as well.
14:16:46 <blogan> sbalukoff: sure
14:17:10 <sbalukoff> jorgem: I looked through a couple of them (I think you had 9 at the time)?
14:17:17 <blogan> #action blogan creates glossary of terms for rackspace's proposal
14:17:18 <jorgem> correct. we will add more
14:17:19 <mestery> 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 <sbalukoff> 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 <sbalukoff> And that's just the "user" use cases.
14:17:48 <mestery> jorgem: Thanks for hte link, nice work on drafting all of that up!
14:17:58 <jorgem> 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 <enikanorov_> some of the use cases map to particular set of values for attributes
14:18:04 <TrevorV> 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 <enikanorov_> like 'support for XXX balancing algorithm'
14:18:25 <TrevorV> sbalukoff: Specifically with use cases I mean
14:18:25 <sbalukoff> 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 <enikanorov_> i think that we need to have a general consensus on the API
14:18:49 <jorgem> sbalukoff: understood. Likewise for ours.
14:18:50 <enikanorov_> and then flush details
14:18:51 <sbalukoff> TrevorV: It sounds like that might be useful, eh!
14:18:55 <enikanorov_> like attributes and such
14:19:07 <blogan> sbalukoff: same with rackspace, that was always the intention
14:19:16 <sbalukoff> Cool.
14:19:18 <enikanorov_> otherwise we'll gid in the details without producing a decision
14:19:49 <enikanorov_> *dig
14:19:53 <mestery> I think we have a plan on the API front here to move forward, comparing and closing gaps.
14:20:07 <jorgem> 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 <mestery> Can we move on to the SSL discussion now?
14:21:15 <mestery> Seems like there was some interest in talking about that a bit.
14:21:20 <blogan> i have a question about the object model
14:21:23 <sbalukoff> jorgem: That sounds fine to me, mostly... though I'm honestly a little uncomfortable potentially leaving some use cases out.
14:21:23 <blogan> just a quick question
14:21:29 <mestery> blogan: Sure, go ahead please.
14:21:42 <jorgem> sbalukoff: I'm okay with doing all or a subset. It's your call.
14:21:47 <blogan> what happens if the API that is decided on requires a major revamp of the object model?
14:22:15 <sbalukoff> 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 <enikanorov_> how major are you expecting it to be?
14:22:27 <jorgem> sbalukoff: Yes, I'll send you an email.
14:22:39 <sbalukoff> Cool, thanks!
14:22:41 <blogan> 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 <enikanorov_> every proposal changes object model in some way
14:23:08 <enikanorov_> blogan: so far proposals are focused around the same set of objects
14:23:28 <mestery> Should we expect at least minor object model changes here? jorgem sbalukoff enikanorov_??
14:23:32 <enikanorov_> it's better to do anychanges in the way that existing code (even if changed) still works
14:23:33 <vjay> what are the aspects in which comparision will be done? like backward compatibil
14:23:38 <enikanorov_> mestery: absolutely
14:23:45 <sbalukoff> mestery: I think so.
14:23:47 <sbalukoff> But...
14:23:48 <vjay> reuse
14:24:06 <sbalukoff> Stated another way, I think:  Are there any potential changes that are off the table?
14:24:18 <enikanorov_> object model changes in several aspects: attributes, relationships and object being added
14:24:29 <jorgem> mestery: There will definitely be additions since there are new features being requested.
14:24:36 <enikanorov_> i think both proposals imply that
14:24:43 <blogan> 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 <mestery> 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 <mestery> jorgem: Agreed there.
14:25:07 <enikanorov_> blogan: obj model is changed with API obviously
14:25:10 <mestery> blogan: Lets cross that bridge when we get there and make a call as a team at that point.
14:25:16 <blogan> mestery: evolution is fine from a good foundation
14:25:29 <jorgem> I think we should agree on API spec first. Then figure out a transition plan.
14:25:32 <enikanorov_> blogan: the foundation is good enough, actually
14:25:38 <german_> jorgem +1
14:25:41 <mestery> jorgem: +1
14:25:47 <TrevorV> jorgem: +1
14:25:51 <enikanorov_> yes, that would be the right thing to do
14:25:59 <sbalukoff> jorgem: +1
14:26:00 <mestery> Perfect!
14:26:04 <crc32> yea like evolution works but some APIs have to go extinct for this to work.
14:26:04 <tmc3inphilly> +1
14:26:10 <mestery> OK, anything else on the API front now?
14:26:23 <samuelbercovici> jorgem: +1
14:26:25 <mestery> I think we have a good plan for the next week to address this.
14:26:32 <vjay> should we discussion on what aspects to be considered during comparison?
14:26:42 <rm_work> my questions about SSL are specific to sbalukoff's API proposal, so does that count for API discussion or SSL discussion? :)
14:26:42 <mestery> And we should definitely continue the ML discussions on the API Front once the comparison spreadsheet is done.
14:26:44 <vjay> sorry discuss
14:26:53 <blogan> no im good
14:27:06 <mestery> rm_work: Lets answer vjay's question then go to SSL :)
14:27:11 <jorgem> vjay: I think that is a good idea. What metrics to compare on?
14:27:29 <jorgem> before we go into SSL
14:27:32 <sbalukoff> vjay: I think our plan was to compare / contrast workflows for specific use cases, and present this in a spreadsheet.
14:27:32 <mestery> vjay: I think we're covering all use cases and mapping APIs to the use cases, right jorgem sbalukoff?
14:27:49 <sbalukoff> mestery: Yes.
14:28:05 <mestery> vjay: Does that answer your question?
14:28:08 <samuelbercovici> I think that probably the first 8 use cases should be fine to see how workflows would differ
14:28:12 <sbalukoff> 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 <vjay> ok.
14:28:32 <vjay> thats fine
14:28:39 <mestery> OK, lets move on to SSL.
14:28:44 <mestery> rm_work: The floor is yours. :)
14:28:51 <rm_work> 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 <rm_work> *etc
14:29:13 <rm_work> mestery: heh, well I don't have MUCH, just trying to understand how SSL Term works in sbalukoff's proposal
14:29:33 <rm_work> 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 <rm_work> 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 <sbalukoff> 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 <sbalukoff> rm_work: That specific option could be added.
14:31:27 <rm_work> yeah, ok
14:31:38 <rm_work> I might worry it would be confusing when not explicit :)
14:31:42 <sbalukoff> 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 <samuelbercovici> SSL session_id is usualy a persistency property for HTTPS
14:31:53 <sbalukoff> Since there's a maintenance cost going forward for having them.
14:32:15 <blogan> sbalukoff: that is a good goal to have
14:32:17 <sbalukoff> samuelbercovici: Yep.
14:32:37 <rm_work> that's all I had :) like I said, just wanted to clear that up
14:32:40 <sbalukoff> blogan: There are other implications like that subtly hidden in my API proposal.
14:32:41 <samuelbercovici> so we could have had HTTPS for non teminated protocols and TLS for terminated ones
14:33:16 <rm_work> samuelbercovici: so that the protocol more clearly implies what's happening with regard to termination?
14:33:26 <sbalukoff> 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 <samuelbercovici> this is a good things as there are capabilities available for TLS which should not be available for HTTPS
14:33:52 <rm_work> 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 <german_> +1
14:34:31 <samuelbercovici> 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 <rm_work> ah, true
14:34:43 <sbalukoff> 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 <german_> yes
14:35:02 <samuelbercovici> actualy TLS has all the capabilitiy of HTTP
14:35:10 <samuelbercovici> from a configuration perspective
14:35:13 <crc32> SSL session id is apart of the TLS handshake so it could be used on TCP as well right?
14:35:19 <rm_work> 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 <sbalukoff> rm_work: The devil is always in the details. :)
14:35:56 <samuelbercovici> crc32: but if it is a pure TCP protocol it should not be avialble for selection
14:36:02 <tmc3inphilly> from an end-user of the api having a specific call out for termination would be best
14:36:09 <tmc3inphilly> less abiguity
14:36:29 <samuelbercovici> i agree
14:36:34 <rm_work> Well, if the protocols were more clear in specifying that they were controlling SSLTerm/Passthrough, it would be fine I think
14:36:35 <sbalukoff> 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 <tmc3inphilly> think of least common denominator (customers)
14:36:44 <rm_work> as it is, it was ambiguous enough to cause me confusion
14:36:49 <sbalukoff> ie. some other protocol support that's also using transport layer security?
14:36:56 <sbalukoff> If so, can we get that added to the use cases?
14:37:28 <rm_work> HTTP / HTTPS (Terminated) / HTTPS (Passthrough) / TCP
14:37:38 <samuelbercovici> sbalukoff: obviously HTTPS on a non default 443 port does not meet your case, right?
14:38:43 <samuelbercovici> sbalukoff: in your proposal there is a difference between SNI and a siongle certificate, why is this?
14:39:03 <rm_work> 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 <sbalukoff> samuelbercovici: Actually HTTPS on a non-standard port is still HTTPS, in my opinion.
14:39:14 <crc32> 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 <sbalukoff> Covered under the same use case.
14:39:22 <rm_work> sbalukoff +1
14:39:28 <samuelbercovici> balukoff: yes i agree
14:39:33 <TrevorV> 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 <rm_work> samuelbercovici: and I think it is because there should be a default cert for fallback if no SNI matches?
14:40:01 <sbalukoff> 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 <rm_work> oh wait, i might be reading the wrong section
14:40:30 <sbalukoff> So on the SNI stuff:
14:40:41 <samuelbercovici> rm_work: I think that might be addressed by ordering the list
14:40:49 <crc32> fair enough. I just wonder if any one wants LDAPS to session persisted.
14:40:56 <sbalukoff> 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 <sbalukoff> 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 <rm_work> 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 <sbalukoff> 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 <sbalukoff> Just specify the default_certificate_id.
14:43:14 <sbalukoff> 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 <samuelbercovici> default certificate must be provided in case SNI is not supported
14:43:30 <sbalukoff> samuelbercovici: Correct.
14:43:49 <samuelbercovici> but it can be the 1st in the list
14:43:50 <sbalukoff> Though, with very few exceptions, all modern browsers can do SNI.
14:43:58 <samuelbercovici> if no SNI, than only one certificate
14:44:06 <sbalukoff> Yes.
14:44:23 <sbalukoff> That works too...
14:44:23 <samuelbercovici> so why are there two diferent entries?
14:44:34 <rm_work> 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 <sbalukoff> 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 <sbalukoff> Er... pool that gets selected by an L7 policy.
14:45:29 <sbalukoff> 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 <sbalukoff> As it is, though...
14:45:40 <rm_work> but if they don't want more than one....
14:45:41 <samuelbercovici> the other part is that I prefer to specify trusted certificates using the same scemantics on a differetn list
14:45:54 <rm_work> they shouldn't have to set up SNI, which they would if we removed the "default cert" concept
14:46:04 <sbalukoff> rm_work: Aah! Yes, you're right.
14:46:27 <samuelbercovici> this might be more easier than to ustilize if certificates are actualy stores in Barbican
14:46:53 <sbalukoff> 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 <sbalukoff> The way I suggested uses fewer objects but is certainly more confusing.
14:47:07 <tmc3inphilly> how would that work for an off-the-shelf LB on the backend?
14:47:47 <sbalukoff> tmc3inphilly: Sorry, I'm not sure who you're asking, and that "that" is in your question.
14:47:59 <sbalukoff> and what "that" is.
14:48:04 <sbalukoff> Sheesh. Sorry, guys, it's early.
14:48:12 <tmc3inphilly> sorry the management of certs through Barbican
14:48:17 <samuelbercovici> 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 <rm_work> I assume it would be "transparently"
14:48:48 <rm_work> samuelbercovici: I am not sure allowing control of cipher suites is a great idea in general <_<
14:49:03 <tmc3inphilly> you should be able to specify protocols (force TLS 1.2)
14:49:04 <rm_work> I guess if it is an absolute requirement for some...
14:49:12 <sbalukoff> 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 <tmc3inphilly> sbalukoff gotcha
14:49:47 <samuelbercovici> sbalukoff: yes, this is how it shoould be treated
14:49:49 <rm_work> 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 <rm_work> done
14:50:00 <sbalukoff> 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 <mestery> rm_work: +1 to that
14:50:36 <crc32> 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 <samuelbercovici> sbalukoff: ok. the one I have in addition
14:50:50 <sbalukoff> 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 <tmc3inphilly> how about cipher suite profile?
14:51:05 <rm_work> 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 <crc32> sbalukoff'
14:51:08 <samuelbercovici> sbalukoff: you are right
14:51:09 <sbalukoff> crc32: It could be done that way, too, yes.
14:51:40 <tmc3inphilly> pre-defined cipher suite profiles
14:51:46 <enikanorov_> folks, i suggest we switch to the summit agenda
14:51:46 <sbalukoff> 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 <crc32> sbalukoff: No I think the attempt was to store the CIPHER suit at the loadbalancer layer.
14:51:52 <enikanorov_> we have 10 minutes left
14:52:07 <mestery> 10 minutes left, yes. :)
14:52:11 <mestery> Actually now 8
14:52:17 <samuelbercovici> sbalukoff: it should be on the tenant
14:52:23 <german_> and we can't run over :-)
14:52:23 <sbalukoff> Ok, further SSL questions on the mailing list!
14:52:33 <mestery> sbalukoff: +1!
14:52:38 <german_> +1
14:52:47 <mestery> OK, so, Summit Agenda.
14:53:00 <mestery> 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 <enikanorov_> i think there should be 2 general discussions
14:53:23 <samuelbercovici> concluding the API decision would be top
14:53:25 <enikanorov_> which are user requirements and operator rquirements
14:53:48 <mestery> 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 <enikanorov_> right
14:54:02 <samuelbercovici> to me the goal form the summit is to have action items, tasks and prople allocated so work could start
14:54:13 <enikanorov_> i also think that's not necessary to devide those two in 1:1 ratio
14:54:16 <sbalukoff> samuelbercovici: +1
14:54:36 <samuelbercovici> mestery: I think we can discuss 1st with VPNaaS and Barbican on ML
14:54:37 <mestery> 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 <enikanorov_> 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 <mestery> samuelbercovici: Yes, in fact we discussed in the advanced services meeting yesterday.
14:54:55 <enikanorov_> what do you think on this?
14:55:09 <jorgem> 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 <mestery> 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 <enikanorov_> mestery: sure!
14:55:45 <mestery> jorgem: I think we should proceed on ML for that one and hope to close before the summit.
14:55:50 <samuelbercovici> enikanorov_: gr8
14:56:07 <jorgem> mestery: Close on API, transition plan or both?
14:56:10 <rm_work> 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 <samuelbercovici> 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 <enikanorov_> rm_work: that's interesting
14:56:54 <sbalukoff> 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 <enikanorov_> rm_work: can you send me an email with your thoughts on this?
14:57:05 <rm_work> sbalukoff: yeah, I assume this will be a group effort
14:57:15 <sbalukoff> Yep.
14:57:20 <samuelbercovici> rm_work: +1
14:57:21 <german_> yep
14:57:24 <rm_work> enikanorov_: I'll try to work something up today. Just you, or just throw it up on the ML?
14:57:31 <mestery> jorgem: API, sorry. :)_
14:57:37 <crc32> ML would be fine rm_work.
14:57:38 <enikanorov_> yeah, ML is even better
14:57:38 <german_> ML, please
14:57:42 <rm_work> kk
14:57:45 <mestery> samuelbercovici: Agreed
14:58:28 <mestery> OK, we're about out of time.
14:58:33 <mestery> Lets wrap this one up now.
14:58:33 <enikanorov_> ok, so we'll have another meeting before the summit
14:58:39 <mestery> We have some good action items!
14:58:43 <enikanorov_> yeah
14:59:03 <samuelbercovici> gr8 stuff!!!
14:59:09 <jorgem> Alright, thanks everyone!
14:59:11 <sbalukoff> Yay!
14:59:12 <rm_work> ah I suppose...
14:59:22 <rm_work> #action rm_work Start driver discussion on ML
14:59:36 <mestery> Thanks everyone, we'll see you all in-channel or on the ML!
14:59:51 <samuelbercovici> bye
14:59:54 <vjay> thanks, bye
14:59:55 <enikanorov_> see you, bye
14:59:57 <german_> bye
15:00:02 <rm_work> thanks!
15:00:05 <TrevorV> thanks!
15:00:09 <tmc3inphilly> ciao
15:01:10 <mestery> enikanorov_: Did you do #endmeeting?
15:01:17 <sbalukoff> Nope.
15:01:20 <enikanorov_> not yet
15:01:23 <mestery> K
15:01:23 <enikanorov_> #endmeeting