14:01:29 <enikanorov> #startmeeting neutron lbaas
14:01:29 <openstack> Meeting started Thu Apr 10 14:01:29 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:32 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:38 <sbalukoff> Hello!
14:01:39 <ptoohill> hello
14:01:40 <enikanorov> hi
14:01:41 <sballe> hi
14:01:42 <marios> hi
14:01:43 <rm_work|away> yo
14:01:44 <obondarev> hi all
14:01:44 <crc32> over
14:01:52 <iwamoto> hello
14:01:52 <aburaschi> hi
14:01:53 * pcm lurking as usual
14:01:54 <enikanorov> hi everyone
14:02:07 <vjay> Hi
14:02:12 <german_> hi
14:02:13 <enikanorov> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_10.04.2014
14:02:14 <TrevorV> Morning!
14:02:21 <blogan> hello everyone
14:02:25 <enikanorov> here's meeting agenda ^^^
14:03:30 <enikanorov> i'm glad to see so many ppl on the meeting, but that's sad that almost none participated in the discussions on ML
14:03:54 <sbalukoff> Indeed.
14:04:22 <enikanorov> one of those was to try to propose single-call API that is afvored by some of you
14:04:45 <enikanorov> Sam Bercovici has prepaired a list of use cases, written from a user perspective
14:05:06 <enikanorov> so it would be nice to see how those use cases could be implemented with such API
14:05:43 <enikanorov> i think if we don't get any proposal till next meeting, we may close this topic as not getting much attention
14:06:15 <hvprash> where are we tracking the use cases ? i am confused if its the wiki or the google docs.we have some use cases and feature requests
14:06:16 <enikanorov> #link https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit
14:06:19 <rm_work> i'll try to set aside time this week for that… still getting used to ML stuff :/
14:06:26 <sballe> ditto
14:06:55 <enikanorov> i hope all of you are tracking openstack-dev ML for [Neutron][LBaaS] emails
14:08:01 <enikanorov> markmcclain: hi
14:08:12 <sbalukoff> FWIW, it wasn't exctly a quiet week for those of us who still get pulled in to do hands-on work (ie. "heartbleed"), but I'm not making excuses. :)
14:08:26 <markmcclain> enikanorov: hi
14:08:30 <enikanorov> yeah, that one made a lot of noise
14:08:39 <german_> same here
14:08:56 <enikanorov> markmcclain: i'd like to continue the discussion of 'networking functions vs virtualized appliances'
14:09:14 <enikanorov> could you elaborate your thinking on why can't we provide API in both styles
14:09:33 <enikanorov> i think 'function' is a subset of 'appliance'
14:09:44 <enikanorov> i'm just trying to better understand the argument
14:09:51 <jorgem1> hello, sorry I'm late :/
14:11:04 <markmcclain> enikanorov: providing both styles in the API can cause confusion
14:11:13 <german_> +1
14:11:24 <jorgem1> enikanorov: Sorry for not starting the "single api call" discussion on the ML. Been quite busy. I will start that this week.
14:11:31 <enikanorov> by 'styles' i mean the following thing:
14:12:06 <enikanorov> particularly, the 'virt appliance' agrument was about 'loadbalancer instance' proposal, where user works with instance and it's objects
14:12:14 <jorgem1> #action Jorge to engage in "Single API" discussion on ML
14:12:22 <enikanorov> in this sense, the 'vir appliance API' is just another resource
14:12:30 <enikanorov> which could be used as extra
14:12:52 <markmcclain> right but extra = confusion
14:13:02 <enikanorov> if user wants to work with their loadbalancing objects as a group - they use instance
14:13:16 <enikanorov> if not - they use particular objects and don't care
14:13:53 <markmcclain> that seems confusing because now you have two ways to interact with something
14:14:26 <german_> REST prefers to have only one way to interact with a resource
14:14:42 <enikanorov> markmcclain: well, you can create a port on a network, and you may or may not provide fixed_ip
14:14:46 <rm_work> not actually sure how REST prefers anything...
14:14:48 <enikanorov> i treat it like that
14:14:48 <markmcclain> german_: users and doc authors do too :)
14:14:52 <rm_work> but I agree it could be confusing
14:15:16 <enikanorov> if you provide fixed_ip, that allows you to specify subnet
14:15:24 <enikanorov> if you don't care - you may omit it
14:15:34 <sballe> markmcclain, using hte API as they are today are confusing
14:15:49 <blogan> +1
14:15:56 <sbalukoff> +1
14:15:59 <rm_work> enikanorov: yeah, that's an issue of sane default values
14:16:10 <jorgem1> +1
14:16:37 <markmcclain> sballe: agreed that is why a new version makes sense
14:16:57 <enikanorov> another problem that 'instance' can solve is the application of 'service requirements'
14:17:02 <enikanorov> e.g. flavors/capabilities/etc
14:17:15 <markmcclain> enikanorov: I am not following why fixed_ip even matters
14:17:16 <enikanorov> i mean to which object should those requirements be applied?
14:17:30 <blogan> markmcclain: if a load balancer instance is confusing and the current API is confusing, do you have any recommendations for a less confusing API?
14:17:34 <sballe> markmcclain, so I was hoping that we had a way of fixing them. so if we move forward with a new version what are the constraints in your opinion. I only hear we cannot do this or that but nothing around how we should do it
14:18:02 <enikanorov> markmcclain: that's was example of similar approach, in my opinion
14:18:52 <markmcclain> blogan: I've been heads down with RC2 work, so haven't had the opportunity to sketch out what it should look like
14:20:06 <jorgem1> markmcclain: Just a general question. If we need buy in from you or core contributors but they are busy on other things then how do we make decisions? This is a question a lot of us have had in the last few meetings.
14:20:29 <sballe> markmcclain, I totally understand you are super busy with RC2 work but now our work is getting staled too.We have a lot of momentum and energy in the LBaaS group today but we cannot move forward
14:21:01 <sballe> jorgem1, + 1
14:21:18 <markmcclain> sballe: at this point I don't see any constraints with redeveloping the REST API mainly because if we do this properly then the exercise of how to render compatibility for users of the old version should be doable
14:21:47 <jorgem1> markmcclain: I think we just need some guidance on what you mean by that.
14:21:55 <sballe> +1
14:22:01 <markmcclain> jorgem1: that is the tricky part of this time of year is the core team is focused on the release
14:22:17 <enikanorov> markmcclain: that's why we need even the very minimum of your idea of how the API should look like
14:22:22 <markmcclain> now that RC2 is out most of the team's attention can now be focused on juno
14:22:35 <enikanorov> because you seem to not like anything being proposed so far :)
14:22:48 <markmcclain> so I would expect as more of the cores ramp up into more phases of the design process
14:23:00 <jorgem1> markmcclain: Understandable. I'm just looking for an alternative because sballe is right, there is a lot of energy right now and people are pumped to get stuff completed.
14:24:26 <markmcclain> enikanorov: my minimum idea is something that I user centric that provides meets the high priority use cases
14:25:27 <markmcclain> the user should not need to care how things are implemented on the backend other than to indicate their class of service desire via flavor (or whatever we end up calling it)
14:25:41 <sbalukoff> Sounds like we're going to need to go through the work of making a new API proposal before we're going to have anything concrete to discuss with core?
14:25:43 <enikanorov> markmcclain: that is totally understood and nobody is questioning it
14:26:04 <blogan> i think the real hangup here is what is defined as a confusing API and what is not a confusing API
14:26:13 <sballe> blogan, +1
14:26:13 <blogan> because we agree the current one is confusing
14:26:16 <enikanorov> blogan: right
14:26:44 <enikanorov> let's make it an AI so every one will write your vision of what is confusing about existing API
14:26:45 <blogan> but a lot of us agree that a load balancer instance would be less confusing if not downright sensible
14:27:01 <sballe> blogan, 100% agree
14:27:17 <german_> we should not constrain ourselves by just looking at the existing API
14:27:27 <sballe> german_, +1
14:27:29 <enikanorov> #action outline issues of existing LBaaS  API
14:27:42 <rm_work> for one, it seems like the basic expectation for <Anything>AsAService is "Object of type <Anything>"
14:28:17 <german_> markmcclain, you have an example of a good API (not LB)
14:28:25 <rm_work> so, from a consistency perspective, i think a LB object is a valid assumption for a user
14:28:52 <markmcclain> I think we need to sketch out what the REST endpoints look like
14:29:35 <sbalukoff> ...which brings us back to object discussions? I think we tried starting with that approach...
14:29:36 <markmcclain> the LB object in most cases is really an implementation detail not something the user cares about
14:30:09 <enikanorov> markmcclain: i think it's mostly a concept of 'a unit of configuration'
14:30:13 <ptoohill> unless hes having to make many calls that could be done in a single call, thus simplifying the work needed to spin up a load balancer
14:30:16 <enikanorov> something you can turn on/off
14:30:20 <enikanorov> destroy
14:30:27 <enikanorov> or change capabilities
14:30:29 <enikanorov> or migrate
14:30:48 <markmcclain> at the simple case a user wants a VIP to be mapped to a set of members
14:30:50 <enikanorov> i dunno how to apply all these actions without the concept
14:31:08 <enikanorov> right, but for simple cases existing API is totally ok
14:31:13 <enikanorov> even if confusing
14:31:22 <rm_work> i still have problems with our definition of VIP, but i guess it's just me
14:31:30 <blogan> i would say at the simple case a user wants a load balancer to load balance members
14:31:35 <sbalukoff> rm_work: It's *NOT* just you.
14:31:41 <markmcclain> enikanorov: the current API leaks out what is actually balancing
14:31:42 <german_> blogan +1
14:31:43 <sballe> blogan, +1 I agree
14:31:55 <rm_work> sbalukoff: ok good, because i was starting to feel like a broken record whenever VIP came up in conversation...
14:31:56 <enikanorov> markmcclain: you mean... ?
14:32:12 <markmcclain> rm_work: what is your issue with the definition?
14:32:42 <rm_work> VIP has a definition that is widely used: Virtual IP
14:32:51 <german_> ok, so the load balancer is basically an attribute to a "pool of nodes"
14:32:57 <rm_work> that is very much not the definition we use
14:33:14 <markmcclain> rm_work: agreed
14:33:22 <enikanorov> german_: and that's how existing API works. althouth we call it a Pool
14:33:25 <sbalukoff> "Virtual IP" is not "virtual IP plus port" :)
14:33:41 <TrevorV> markmcclain: "implementation detail" or not, if not calling it a "load balancer" what would it be called?  "instance" seems extremely vague to me
14:33:43 <sbalukoff> (In other contexts)
14:33:46 <markmcclain> that is why crafting a new IP allows us to align with the common usage
14:33:52 <markmcclain> s/IP/API/
14:34:23 <sbalukoff> markmcclain: Agreed!
14:34:27 <sballe> +1
14:35:00 <sbalukoff> I think the crux of the problem is that a less-confusing API that most of us here want to create involves the concept of a (probably virtual) load balancer.
14:35:11 <sbalukoff> But we're being told that's an implementation detail
14:35:18 <sbalukoff> Which doesn't seem like it is to me..
14:35:27 <blogan> +1
14:35:30 <ptoohill> +1
14:35:30 <TrevorV> +1
14:35:32 <rm_work> I am not sure how it is an implementation detail, it is an entirely logical construct :/
14:35:32 <sballe> +1
14:35:34 <rm_work> +1 sbalukoff
14:35:38 <sbalukoff> How one makes a "load balancer" work from an operator perspective is still up to the operator.
14:36:08 <german_> there are many ways to load balance, e.g. DNS round robin but to abstract that would be tough
14:36:13 <sbalukoff> Yes, the user needs to understand what the concept of a "load balancer" is.
14:36:35 <sbalukoff> But they're doing a pretty good job understanding what a "router" is and what a "virtual server" is.
14:36:42 <sbalukoff> This doesn't seem like much of a stretch.
14:36:42 <enikanorov> i was under impression that user was configuring LB appliance and then has moved to the cloud
14:36:56 <enikanorov> where the same concepts apply, but without knowing your backend
14:37:13 <sbalukoff> enikanorov: +1
14:37:26 <TrevorV> sbalukoff: You're correct, they can understand these things, but a virtual server is called exactly that, not something like "instance"
14:37:28 <markmcclain> a router is a functional and not necessarily a box
14:37:30 <german_> as rmwork said last meeting many of our users are wen developers who just slap a load balancer in front of web servers
14:37:40 <enikanorov> lb instance is functional as well
14:37:49 <sbalukoff> markmclain: Exactly! So is a load balancer!
14:37:51 <jorgem1> Since I spent a lot of time with parts of the community on the Atlas API I am going to make a proposal using it as a start. I will try to incorporate everything we have in terms of requirements. I would suggest others draft up their version of an API too.
14:38:09 <markmcclain> jorgem1: sounds like a good place to start
14:38:16 <rm_work> +1
14:38:18 <sballe> jorgem1, +1
14:38:27 <enikanorov> jorgem1: cool!
14:38:30 <german_> +1
14:38:55 <jorgem1> #action Jorge to create API proposal based off of Atlas API spec.
14:39:04 <markmcclain> when we're virtualizing functions the important thing is not that we feel compelled to replicate what a physical topology would look like
14:39:22 <tmc3inphilly> if you do not think load balancer is abstract enough, perhaps we should change the name of the project as well
14:39:26 <jorgem1> at least then we can have something to argue about
14:39:49 <sbalukoff> jorgem1: +1
14:40:01 <enikanorov> not sure 'instance' is about physical topology
14:40:48 <tmc3inphilly> a load balancer is a logical/abstract entity that does not implicate any particular implementation detail
14:41:01 <jorgem1> On a side note, only Rackspace and Blue Box Group contributed to the deployment scenario statistics page. Could HP, Mirantis, Ebay/Paypal and others provide their data so we can drill in on what requirements should take priority?
14:41:04 <enikanorov> yes, that thinking was behind the proposals
14:41:12 <sbalukoff> At least, no more than a neutron "router" does.
14:41:22 <enikanorov> jorgem1: Mirantis is not a cloud provider
14:41:24 <jorgem1> That should help also in defining the API
14:41:33 <enikanorov> so we don't have such statistics
14:41:42 <jorgem1> Do you all have any stats?
14:41:45 <jorgem1> that would help?
14:41:59 <sbalukoff> enikanorov: Yes, anything you can provide to help inform would be useful.
14:42:23 <jorgem1> Otherwise, we will be making decisions off the data we do have.
14:42:31 <enikanorov> sbalukoff: no such stats, sorry :)
14:42:31 <sballe> jorgem1, we priotitized the features  on the first page.
14:42:46 <jorgem1> sballe: I saw that. Thank you.
14:42:57 <enikanorov> also, please consider clarifying to Sam those spreadsheets
14:42:58 <sbalukoff> (That is, I assume you have customers, and are involved in load balancing in some way-- what features are they most requesting, or, if they're delivered, considered most vital?)
14:43:11 <enikanorov> i think Radware has stats also and Sam wanted some clarifications
14:44:01 <enikanorov> one of the clarification i can recall is the http+https use case
14:44:13 <enikanorov> i think this implies no https termination
14:44:37 <rm_work> not necessarily? though i'll have to check the context
14:44:41 <jorgem1> sbalukoff: Agreed. However, while requested features is good I would argue that actual data is better. Kind of "walk the walk" is better than "talk the talk".
14:44:46 <sballe> enikanorov, we are more interested in the SSL termination
14:45:04 <jorgem1> sbalukoff: If we can get both that would be a plus.
14:45:12 <enikanorov> sballe: rm_work: i'm talking particularly about having two vips on 1 device
14:45:26 <sbalukoff> jorgem1: Yep. But even knowing what features they really want is better than nothing, eh. (eg. something like the prioritized list sballe provided)
14:45:30 <enikanorov> no about https termination itself, which deman is not questioned
14:45:32 <rm_work> enikanorov: err, but they would have the same IP? so only one VIP
14:45:39 <jorgem1> sbalukoff: Agreed.
14:45:48 <enikanorov> rm_work: right, one IP, different tcp ports
14:45:50 <tmc3inphilly> one vip multiple ports?
14:46:06 <enikanorov> yes. per current API glossary
14:46:10 <rm_work> ffff
14:46:14 <enikanorov> sorry!
14:46:16 <rm_work> lol
14:46:32 <enikanorov> may call it listeners
14:46:34 <sbalukoff> Haha
14:46:35 <rm_work> well anyway, we do have SSL Termination that also has HTTP as well
14:46:50 <rm_work> so, listening on HTTP:80 and HTTPS:443 terminated
14:47:00 <jorgem1> I answered this on the ML.
14:47:00 <rm_work> we call it "mixed-mode"
14:47:03 <tmc3inphilly> perhaps someone wants to load balance DNS which requires TCP 53 and UDP 53
14:47:07 <enikanorov> rm_work: the question was why is that needed for the web app
14:47:11 <jorgem1> A lot of sites have mixed content.
14:47:15 <sbalukoff> rm_work: That's our most common deployment scenario.
14:47:24 <rm_work> why it is needed is not really important when we have stats that it is used
14:47:32 <enikanorov> jorgem1: if you terminate https, then how would site knows?
14:47:33 <rm_work> the customers do what they need, we don't usually question it :P
14:47:37 <jorgem1> I wouldn't do it personally but there are plenty of web sites out there that do.
14:47:41 <ptoohill> headers
14:48:01 <enikanorov> headers, but the connection is actually http, nice
14:48:07 <ptoohill> indeed
14:48:10 <rm_work> enikanorov: on the backend, on a private network
14:48:16 <enikanorov> rm_work: sure
14:48:18 <rm_work> still prevents MITM
14:48:35 <enikanorov> ok
14:48:38 <rm_work> http browse a site -> go to store page -> store pages are over HTTPS
14:48:42 <jorgem1> which reminds me…SSL re-encryption should be added to the requirements if it isn't already there.
14:49:14 <vjay> Hi All, Would stats from appliance/Vendor side be helpful. That data will be mostly from a "non-cloud" environment.
14:49:17 <enikanorov> sorry for my ignorance - why not pass it through then?
14:49:18 <rm_work> also i believe we would need that same setup if we were to put redirect rules in (for HTTP->HTTPS automatic redirect)
14:49:28 <sbalukoff> vjay: Yes!
14:49:31 <jorgem1> vjay: Yes!
14:49:34 <rm_work> enikanorov: need to mangle headers like x-forwarded-for
14:49:37 <rm_work> can't do that if it
14:49:42 <rm_work> is HTTPS passthrough
14:49:43 <sbalukoff> vjay: Please put it in the google spreadsheet!
14:49:44 <ptoohill> user does not want to hand ssl connection in backend
14:49:45 <enikanorov> ok, got it
14:49:49 <ptoohill> handle
14:49:54 <vjay> I have to get data & clearance though.
14:49:58 <bbaby> +1 Vijay. We have lb stats data but not necessarily from cloud environment
14:50:03 <hvprash> +1
14:50:07 <jorgem1> vjay: Here is the link ==> https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0
14:50:29 <sbalukoff> vjay: Please share whatever you're allowed to. :)
14:50:42 <sbalukoff> Even if it's just a prioritized list of features you need.
14:50:42 <vjay> sure
14:52:22 <jorgem1> bbaby: Any data is good data right now. It will help us prioritize.
14:52:37 <jorgem1> bbaby: Feel free to add it.
14:52:44 <bbaby> ok.
14:52:58 <bbaby> Also the feature usage on https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0 is again specific to cloud ?
14:53:01 <sbalukoff> And the sooner you can add your data, the better.
14:53:14 <enikanorov> i think that beside those features we need not to forget about 'least common denominator' of loadbalancing features
14:53:18 <enikanorov> which comes first
14:53:25 <enikanorov> bbaby: no
14:54:18 <jorgem1> enikanorov: Such as? If they aren't in the requirements we should add them for visibility and clarity.
14:54:47 <jorgem1> My idea with the requirements page was to capture everything, no matter how trivial.
14:54:59 <german_> +1
14:55:00 <sbalukoff> jorgem1: +1
14:55:01 <enikanorov> i think the basic features beside 'single vip+single pool' is 'mixed mode', L7 switching and SSL termination
14:55:05 <rm_work> maybe we can emphasize which are MVP reqs somehow>
14:55:14 <enikanorov> that was decided at Icehouse summit
14:55:15 <sbalukoff> It's a good idea to have the "definitive list" of the problems we're trying to solve.
14:55:23 <tmc3inphilly> what about algorithims?
14:55:31 <sbalukoff> Even if some are very obvious.
14:55:50 <german_> yes, and then we prioritize
14:56:13 <sballe> +1
14:56:20 <enikanorov> agreed.
14:56:22 <markmcclain> enikanorov: at this point we're not bound to previous decisions
14:56:41 <jorgem1> Correct, most of the trivial requirements are already met too so those will be easy wins :)
14:56:50 <enikanorov> markmcclain: right, but some work has been already done, and those features really seem to be basic
14:56:51 <markmcclain> we can re-examine previous decisions
14:57:14 <enikanorov> and they are captured in the requirements also
14:58:31 <enikanorov> ok, it's nearly a time to end the meeting, do we have something left?
14:58:33 <jorgem1> #action Add "least common denominator" requirements to wiki
14:58:40 <enikanorov> i think we have a bunch of items to work on
14:58:48 <sbalukoff> Yep.
14:58:50 <jorgem1> indeed
14:58:53 <german_> jorgem1 please call it MVP
14:58:55 <rm_work> i will try to be on the ML more...
14:59:13 <sballe> same here
14:59:17 <jorgem1> german_: Shoot…how do you update an action item?
14:59:21 <enikanorov> yes please, meeting is too short to discuss everything in detail
14:59:34 <sbalukoff> Ditto... once I get freed up from being pulled into heartbleed work. XD
14:59:47 <enikanorov> so please use ML, wiki, paste.openstack.org, and everything that helps to illustrate your ideas
14:59:48 <blogan> double ditto
14:59:54 <jorgem1> sbalukoff: Oh heartbleed. We had some fun too :)
15:00:16 <enikanorov> thanks everyone for joining the meeting!
15:00:20 <jorgem1> Thanks!
15:00:22 <enikanorov> #endmeeting