14:00:35 <enikanorov_> #startmeeting neutron lbaas
14:00:36 <openstack> Meeting started Thu Jan 23 14:00:35 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:40 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:45 <enikanorov_> I've send an email with lbaas status update yesterday
14:02:03 <enikanorov_> we have a few items to discuss
14:02:21 <samuelbercovici> hi all
14:02:23 <enikanorov_> they are ssl extension, l7 rules and API
14:02:26 <enikanorov_> Hi Sam
14:03:11 <enikanorov_> on ssl extension... i've asked Mark to join, but apparently he's travelling, so i'm not sure if he is able to attend
14:03:23 <enikanorov_> oh, cool
14:03:28 <markmcclain> o/
14:03:29 <enikanorov_> markmcclain: hi
14:03:34 <enikanorov_> right on time :)
14:03:42 <enikanorov_> (i've just mentioned you)
14:03:58 <vjay> hi
14:04:04 <enikanorov_> hi vjay
14:04:25 <enikanorov_> so the main item to discuss right now is the API and ssl extension in particular
14:05:03 <vjay> would like to know what is happening to changes and the order of commit planned
14:05:07 <enikanorov_> last time we tried to find approach to add ssl, but we're lacking reliable open source backend for that
14:05:16 <vjay> changes like the loadbalancer instance
14:05:29 <enikanorov_> vjay: we'll discuss it a bit later
14:05:33 <vjay> sure
14:06:23 <enikanorov_> markmcclain: the proposal was to add ssl as vendor extension. as far as I recall you had a concern about 'uneven API experience'
14:06:28 <enikanorov_> could you elaborate?
14:06:49 <markmcclain> enikanorov_: sure
14:07:04 <enikanorov_> because I believe whole ability of choosing provider is about different capabilities, and possibly, different API
14:07:23 <markmcclain> the API can get messy when we start creating extensions to extensions
14:07:38 <markmcclain> say we have to 2 different providers with different capabilities
14:07:44 <enikanorov_> right. but we're already doing it with 'core extensions'
14:08:18 <markmcclain> right but there is a framework for discovery there
14:08:46 <markmcclain> if we have to 2 different providers who support a different feature set how would a consumer consume it?
14:09:11 <markmcclain> and know that say provider A provides SSL support and provider B does not
14:09:27 <enikanorov_> consumer should know that certain resource available with certain service+provider
14:09:43 <markmcclain> enikanorov_: how is that learned?
14:10:04 <markmcclain> it needs to be noted this is similar problem for ml2 too
14:10:08 <enikanorov_> we have a way to know supported extensions. we can add that information there
14:10:20 <enikanorov_> markmcclain: yes, ml2 is similar
14:10:45 <markmcclain> discoverability is a solvable problem
14:10:49 <enikanorov_> [{'service': core, 'provider': 'abc', 'extension': 'def'}]
14:11:07 <samuelbercovici> To move from the "big" extension discussion. SSL is implemented as an extension because: 1: we want to have this up and running as an expeimental API and then get it as part of the standarad API 2: we are not sure yet how the ha proxy implementation will go
14:11:41 <markmcclain> enikanorov_: that is certainly one approach that we can follow
14:12:25 <markmcclain> samuelbercovici: right don't forget there was some discussion about pairing with stunnel to provide a open implementation
14:12:43 <samuelbercovici> markmcclain: correct
14:13:01 <markmcclain> chatting with friends at other companies I know this is a pattern that actively deployed
14:13:05 <samuelbercovici> but the decision to go into the extnesion path was before
14:13:27 <markmcclain> I don't think I'll be able to get them to contribute code though
14:13:29 <sbalukoff> markvan: Outside of Openstack, I've built two load balancer "appliance" products which use stunnel as terminator for SSL + haproxy as load balancer--  this is very reliable.
14:13:40 <samuelbercovici> yes, it is actually the pattern de-facto for ha proxy with ssl
14:14:45 <samuelbercovici> the other part was the move to use something lica babican in the eventual API
14:15:46 <enikanorov_> i think whole question goes down to allowing vendors to implement what their need without being blocked by the lack of opensource solution
14:16:06 <enikanorov_> when it is not a common code (common extension)
14:16:33 <markmcclain> I get that.. I just don't want 4 slightly different implementations in the extensions
14:16:35 <samuelbercovici> enikanorov_: which is an excellent question, it is just not relevant to SSL as SSL is planned to be implemented by averyon, same as L7
14:16:43 <sbalukoff> Well, and sometimes opensource solution might have features vendors don't support (eg. SNI support, SSL cipher selection, etc.)
14:17:02 <enikanorov_> samuelbercovici: but right now this is directly related to ssl
14:17:48 <markmcclain> sbalukoff: yes there should room for supporting different features, but I think we need a baseline first
14:18:00 <sbalukoff> markmcclain: True.
14:18:17 <samuelbercovici> let me rephrase. extensions can be a way for vendors to implement "private" capabilities and it can also be used to impelement "experimental" capabilities untill theyr move to core
14:18:43 <markmcclain> samuelbercovici: that is true
14:19:03 <enikanorov_> right, so I'm asking why we can't make ssl such extension
14:19:04 <markmcclain> but even then we still have to be careful with what we release
14:19:17 <enikanorov_> and then move it to core once we implement stunnel+haproxy
14:19:23 <sbalukoff> markmcclain: Are you arguing that SSL support is so central to LBaaS that it should be a core feature that, for the most part, is implemented the same across vendors?
14:19:26 <markmcclain> because there are security obligations that we implicitly make with the community
14:19:31 <samuelbercovici> For SSL we use "extension" not be cause this is private radware, but because we want to have it as an :experimentl" api
14:20:16 <markmcclain> sbalukoff: I'd like a solid base that as many vendors implement as possible
14:20:29 <sbalukoff> markmcclain: I'm with you on that, eh.
14:20:38 <samuelbercovici> sbalukoff: yes, this is exactly the way this was planned. We have discussed with other load balancer vendors to get to an agreement on the API, same that we did for L7
14:20:43 <enikanorov_> markmcclain: how about vendor-specific features?
14:21:10 <enikanorov_> markmcclain: there are very basic ones, but we can't call them a baseline
14:21:21 <markmcclain> enikanorov_: that's really the crux of the issue
14:21:27 <enikanorov_> like routed-solutions
14:21:31 <enikanorov_> or appliance-based
14:21:33 <markmcclain> we have the ability to iterate over time
14:22:04 <enikanorov_> I don't think every vendor needs to implement them
14:22:36 <samuelbercovici> markmcclain: I agree that we must have a wide baseline with standarad APIs. Baic L4, SSL and L7 and probably a few more should define the base line.
14:23:10 <sbalukoff> enikanorov: So, your point is that because not all vendors are going to implement the same features, and because we want to expose these features somehow, a need for vendor-specific extensions is always going to exist, right?
14:23:30 <enikanorov_> sbalukoff: yes
14:23:59 <enikanorov_> sbalukoff: that was already solved by vmware by making their own service plugin
14:24:12 <enikanorov_> specific to their backend solution
14:24:36 <sbalukoff> So, then it's a matter of deciding what is "core" functionality that almost all vendors should be able to do, so that consumers can rely on that much at least-- and still provide a way to exentend API with vendor-specific features which make vendors' products more useful.
14:24:58 <markmcclain> sbalukoff: yes
14:25:01 <samuelbercovici> enikanorov_: although it might use the same approach, there is difference between stating which standard capabilities are supported and between supporting "private" "non-standard" ones
14:25:25 <vjay> as said earler: L4, SSL & L7 is available with most vendors, it should be part of baseline
14:25:35 <sbalukoff> Agreed.
14:25:48 <markmcclain> that's my feeling
14:26:36 <markmcclain> so taking deliberate steps with the API is really what we want to do here… the freeze is not too far away… I'd rather release code with less features that we know wrk than trying to be cover every customization now
14:26:38 <enikanorov_> agree with vjay
14:27:18 <enikanorov_> markmcclain: agree as well, though I'm more concerned about the ability for vendors to contribute
14:27:41 <markmcclain> enikanorov_: how so?
14:27:44 <enikanorov_> because each month i see patches from vendors which try to amend core lbaas API with their specific bits
14:28:28 <enikanorov_> that's what I'd like to sort out, keeping the API clean but extensible
14:28:50 <markmcclain> right..but that is part of the blueprint process and consensus building
14:28:50 <sbalukoff> enikanov: So they need to be directed to put these in their own vendor-specific extensions. Problem being that there is no way to do vendor-specific extensions just yet?
14:29:19 <sbalukoff> Sorry, enikanorov_
14:29:26 <enikanorov_> the problem that we still undecided if vendor-specific extensions is what we want to see
14:29:53 <enikanorov_> but honestly i don't see another way of supporting a variety of vendors under the same hood of lbaas
14:30:37 <sbalukoff> Good point. So no better ideas (or even competing ideas) have been shared on this?
14:31:13 <markmcclain> yeah the vendor extensions to drivers hasn't really had an idea that's gained momentum
14:31:30 <markmcclain> but that's ok because we can still work in parallel here
14:31:42 <markmcclain> by implementing the common subset into the core API
14:32:10 <markmcclain> and then figuring out how the extension mechanisms would work
14:32:23 <enikanorov_> markmcclain:applications of such framework are:
14:32:34 <enikanorov_> agent scheduling, device binding, router binging
14:32:54 <enikanorov_> all that is backed-specific and really not related to lbaas api itself
14:33:02 <enikanorov_> generec lbaas api i mean
14:34:36 <markmcclain> correct which is why for the new items we should focus on the API first
14:35:47 <sbalukoff> If we want to expose vendor-specific features, I also don't see a good way to do this without providing a mechanism for extending the API. markmcclain, is the concern here that vendors implentations of core features will diverge too much if we don't actually put these feature in the core API?
14:35:52 <enikanorov_> agree, going back to ssl, my point was that making it a vendor extension is just a way of letting some folks (vendors and customers) to move forward and try it
14:36:35 <edhall> sbalukoff, as a customer, that is exactly my concern
14:36:59 <markmcclain> sbalukoff: yeah divergence is one concern
14:37:07 <sbalukoff> edhall: Mine too.
14:37:10 <enikanorov_> implementation of core features should not happen, at best
14:37:19 <enikanorov_> *divirgence
14:37:58 <sbalukoff> Yes. So again, we're back to what's been agreed on as core, plus providing a way for vendors to extend these features, which I think is what enikanorov is advocating.
14:38:24 <sbalukoff> And specifically SSL in this case.
14:39:05 <markmcclain> enikanorov_: I am not excited about the idea of saying here is this optional extension a vendor can implement without us having gone through the process in the opensource version first
14:39:36 <enikanorov_> markmcclain: there are cases where we will not have opensource analog at all
14:40:16 <enikanorov_> for instance, if vendor provides appliance-based solution
14:40:25 <edhall> we should encourage vendors to contribute one
14:40:39 <enikanorov_> he may want to enable some API for cloud operator to manage appliances
14:40:49 <markmcclain> enikanorov_: the API and implementation are two different issues
14:40:52 <enikanorov_> but that's unnecessary for, say, haproxy
14:41:19 <enikanorov_> markmcclain: right, but what would be opensource analog in this case?
14:43:22 <markmcclain> enikanorov_: when we're speaking API were talking about the logical state
14:43:51 <enikanorov_> yes
14:44:08 <markmcclain> so I'm failing to see how appliances impact the API discussion
14:44:54 <markmcclain> appliances are an implementation detail correct?
14:44:57 <enikanorov_> appliances need API to manage. exiting opensource solution (haproxy) doesn't need it
14:45:23 <enikanorov_> or, in fact, it needs different API (agent scheduling)
14:45:52 <markmcclain> appliance management has always seems like a separate issue from the logical API
14:46:09 <enikanorov_> it's not the management itself
14:46:10 <sbalukoff> enikanorov: We could do an haproxy "software appliance" approach which runs LBaaS on compute instances. (I was actually going to propose this myself, as I've implented it twice already? Just need to figure out how to contribute to Openstack in a meaningful way) I really like the idea of being able to split load balancer function away from network as a service function for various reasons.) But that's probably not a qui
14:46:11 <sbalukoff> ck thing to implement here, but it would be analogous to a vendor's appliance solution.
14:46:29 <enikanorov_> it's letting know the service that certain appliance exist ans is available
14:47:20 <enikanorov_> sbalukoff: yes, that would be another use case that could leverage such API
14:47:46 <sbalukoff> And it is purely open source.
14:47:53 <pcarver> Forgive me for jumping in late and in the middle, but I wanted to note that some customers have strong opinions on load balancer appliance vendor.
14:47:54 <markmcclain> sbalukoff: so creating an appliance is viable now
14:48:07 <sbalukoff> markmcclain: Yes.
14:48:13 <markmcclain> just write a driver that spins up and manages VMs for load balancing
14:48:23 <pcarver> So even though we might argue they shouldn't, they may strongly want to select WHICH load balancer vendor their LBaaS runs on
14:48:32 <sbalukoff> markmcclain: Exactly.
14:48:36 <markmcclain> the tenant doesn't really need to know how it is implemented
14:48:36 <enikanorov_> markmcclain: sbalukoff: so vendors should wait for such provider to appear before they can offer their appliance-based solutions?
14:48:44 <sbalukoff> pcarver: This is true.
14:49:06 <markmcclain> pcarver: that's where I think part of our abstractions need work
14:49:19 <markmcclain> we have service providers, but what we really need are flavors
14:49:26 <edhall> As a customer I (1) want to avoid vendor lock-in and (2) not have to maintain a whole layer of software infrastructure to deal with each vendor's implementaion of basic management functions.
14:49:33 <sbalukoff> enikanorov: No, I personally think a way for vendors to extend API is going to be necessary somehow, and I've not yet heard a viable solution other than the one you've suggested.
14:49:53 <sbalukoff> But markmcclain is right that SSL should have a base support in the API as well.
14:49:55 <pcarver> markmcclain: Agreed on functionality, just pointing out that for some customers they may want to be able to control vendor selection via API
14:50:04 <sbalukoff> Which, again, I think was agreed on already (along with L4 and L7)
14:50:31 <markmcclain> pcarver: nothing stops someone from naming the flavors to match the vendors who implement it
14:50:34 <enikanorov_> sbalukoff: i'm all in for making ssl a part of core lbaas API. as far as i understand, the concern is in implementation
14:50:53 <sbalukoff> Got it.
14:50:54 <samuelbercovici> pcarver: if the service provide has the vendor name in it, than the end user, can choose the service provider which also means the vnedor
14:51:01 <markmcclain> using flavors also enables dual vendor strategies and avoids lockins
14:51:20 <pcarver> Ok, makes sense.
14:51:26 <markmcclain> because the deployer can aggregate the providers with similar capabilities into the same flavor
14:52:13 <markmcclain> enikanorov_: yes.. implementation is the tricky part for ssl
14:52:42 <pcarver> Just wanted to make sure folks were aware that some customers, perhaps we might call them "not cloud savvy" want their cloud to be somewhat non-cloudy and guarantee them various specific vendor choices.
14:53:32 <markmcclain> pcarver: yes there is definitely a range of deployers where some users want tenats to have more choice and others were there is less
14:53:51 <pcarver> I personally think they're a bit silly. But they definitely exist and have strong opinions on what they want to buy.
14:53:57 <sbalukoff> pcarver: Yep! I agree this is a primary customer concern.
14:55:01 <enikanorov_> markmcclain: so what is your opinion on ssl for lbaas in I? what is the best plan?
14:55:51 <iwamoto> what we are trying to do is to build mappings from openstack API to vendor specific mgmt API or config files. this cannot be easy
14:56:12 <markmcclain> enikanorov_: I think SSL is a good idea…the real issue is I'm not aware of an implementation where I'm comfortable with it's security
14:56:23 <markmcclain> *API implementation
14:56:46 <sbalukoff> markmcclain: Sending SSL certs via unencrypted rabbit, for example?
14:56:55 <markmcclain> yes
14:56:56 <enikanorov_> i think we need some clear decision before putting more efforts in it
14:57:09 <enikanorov_> are we going to wait for haproxy 1.5 release?
14:57:11 <vjay> mark: just before we close down. want to know your opinion on the hold on NetScaler driver.
14:57:32 <samuelbercovici> enikanorov_: we should not wait for 1.5, 1.4 with stuneel is fine
14:57:38 <sbalukoff> enikanorov: I would say we can do with with stunnel + haproxy approach.
14:57:59 <markmcclain> vjay: I still need to do an in depth review
14:58:06 <enikanorov_> so, should we implement stunnel + haproxy for ssl to merge into core?
14:58:28 <vjay> mark: ok, you need to do a review of the driver?
14:58:30 <markmcclain> stunnel is an acceptable direction to move now
14:58:39 <sbalukoff> mark's concern about security still needs a solution.
14:58:51 <sbalukoff> Specifically, how to send SSL certs.
14:59:13 <enikanorov_> sbalukoff: i think that is solvable.
14:59:27 <sbalukoff> Ok.
15:00:31 <markmcclain> vjay: either I'll do it or it will get picked up by one of the other cores on our team
15:01:08 <vjay> sure, we were planning for i2.
15:01:16 <jd__> (wrapping up?)
15:01:44 <enikanorov_> yes
15:01:47 <enikanorov_> thanks everyone
15:01:51 <sbalukoff> Thanks!
15:01:59 <markmcclain> vjay: I-2 has been cut
15:01:59 <enikanorov_> i think we need to continue to discuss all that in the ML
15:02:03 <enikanorov_> #endmeeting