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