14:00:17 <enikanorov> #startmeeting neutron lbaas
14:00:18 <openstack> Meeting started Thu Apr 17 14:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:04 <enikanorov> ok, so I'd like to dedicate this meeting mostly to continue the API discussion we have had
14:01:09 <ptoohill> hello
14:01:14 <crc32> hello
14:01:16 <aburaschi> hello
14:01:24 <enikanorov> especially because we have a new API proposal
14:01:33 <sbalukoff> Sounds good!
14:01:43 <jorgem> that is still in the works btw ;)
14:02:15 <enikanorov> jorgem: thanks for making the document
14:02:24 <sbalukoff> Yep, thanks!
14:02:27 <german_> +1
14:02:35 <sballe> +1
14:02:38 <enikanorov> i hope every one could take a look at it and evaluate
14:02:41 <rm_work> +1
14:02:49 <crc32> +1
14:02:56 <crc32> I love the new API proposal
14:03:03 <jorgem> enikanorov: No problem. It seems that is has sparked a nice little debate :)
14:03:05 <enikanorov> so I have several concerns on the approach, some technical, some project-wise
14:03:32 <enikanorov> i think i'll start from the project-wise
14:03:47 <enikanorov> in fact it was already spoken out by me
14:03:55 <enikanorov> but i think it makes sense to reiterate
14:04:06 <mestery> Any chance you guys could paste a link to the doc here so it's in the meeting minutes as well?
14:04:15 <sballe> mestery: 1
14:04:17 <enikanorov> mestery: good suggestion
14:04:19 <sballe> +1
14:04:25 <obondarev> #link https://docs.google.com/a/mirantis.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit
14:04:26 <mestery> :)
14:04:32 <mestery> thanks obondarev!
14:04:51 <crc32> https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0
14:04:51 <crc32> https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit?usp=sharing
14:04:51 <crc32> http://openstacksummitmay2014atlanta.sched.org/directory/speakers#.U07hUccd3Dc
14:05:26 <enikanorov> ok, so I was about to say about Neutron API
14:05:46 <enikanorov> Neutron API is quite a low-level, that is focused on manipulating network primitives
14:06:13 <enikanorov> that's the state of the art right now, and it also create a design guide lines for new APIs
14:06:36 <enikanorov> that's why existing LBaaS API generally looks like it is
14:06:51 <sbalukoff> So in other words, in Neutron API, "single-call" deployments don't usually happen?
14:07:17 <enikanorov> single-call is delegated to higher-layer, orcehstration
14:07:19 <sbalukoff> (ie. a user or operator needs to run several API commands in order to have something functional for their cloud.)
14:07:26 <sbalukoff> Got it.
14:07:40 <enikanorov> that could be UI or orchestration tools
14:08:04 <enikanorov> so if we want to embed such capabilities into Neutron - it should be an extra, not the main API
14:08:20 <jorgem> enikanorov: Correct and understandable. However, since load balancing has a lot of L7 features one could put in in a different group that general neutron networking.
14:08:22 <sballe> enikanorov: I thougth the reason for a new API was to make it more usfeu and less confusing. If we cannot change the scope it will be hard to come up with any resonable API from an operator point of view
14:08:48 <sbalukoff> So, it's still somewhat unclear to me what is being looked for when people are asking for the "single call" stuff. Perhaps they could define that? (If not here, then on the mailing list?)
14:08:51 <enikanorov> sballe: that's the part of concerns. hold on! :)
14:09:39 <enikanorov> jorgem: we're still within one project, and the guidelines apply
14:09:44 <crc32> I really wished you had raised this argument much earlier. Instead discussion was allowed to continue even though you were against it all along. I would ask that you refrain from doing this in the future.
14:10:11 <obondarev> sballe: the initial reason was that current API can't handle all requested features
14:10:14 <enikanorov> so project-wise I'm afraid it would be quite difficult to maintain both approaches - regular 'per-object' and 'single-call'
14:10:20 <crc32> Its a respectable argument though.
14:10:43 <enikanorov> so, my personal opinion - i'm not against 'single-call'
14:10:51 <enikanorov> i'm just saying about the costs and constraints
14:11:19 <enikanorov> costs - support, keeping it in sync with featurs that 'per object' model provides
14:11:21 <jorgem> enikanorov: The fact that lbaas is within Neutron may be part of the problem then. The scope of lbaas seems to be much larger than previously thought. Taking a look at the requirements everyone has put down seems to indicate this no?
14:11:22 <sbalukoff> I still think it might be deliverable by using the "good defaults" strategy. :/ But again-- I'm unclear on what we would need to deliver, exactly.
14:11:31 <ptoohill> so, we cant simplify things from the operator perspective because another layer(different tool) should handle that for us?
14:11:54 <jorgem> enikanorov: It seems like we are limited in making decisions because of this as well.
14:12:14 <enikanorov> jorgem: we're limited by the need of making consistent API
14:12:36 <enikanorov> consistent - means that chosing some approach should allow you to do everything that service supports
14:12:36 <mestery> Sorry for jumping in a bit late here, but is the main concern by the operators present here that the LBaaS API needs to be simplified?
14:12:43 <jorgem> enikanorov: please define? how so?
14:13:06 <sbalukoff> mastery: Partially, yet. That and the old a
14:13:12 <german_> mestery, yes we have end users who are not network specialists
14:13:17 <crc32> yea I'm not infavor of the orchistration layer idea cause thats just one step away from requireing heat templates to do the orchistration which adds complexity defeaating the purpose of making a simpler single call method.
14:13:19 <sbalukoff> the old API doesn't provide for the feature set being requested
14:13:23 <enikanorov> jorgem: single call API should allow you do create conf for any use case with a single call
14:13:42 <mestery> OK, now I understand the desire for the single call API then, thanks. :)
14:13:45 <enikanorov> technically it is possible, implementing that will result in the API that Heat has
14:14:23 <enikanorov> given that Heat is focused on that, is it really necessary to bring this capability on a lower layer on which Neutron stands?
14:14:29 <rm_work> enikanorov: i think the proposed API here does that -- or else we have just not managed to come up with a use-case that breaks this
14:14:31 <sballe> enikanorov: I think that bringing Heat is not a good idea. It makes everything more complex.
14:15:24 <crc32> enikanorov: I pretty certaion making heat a mask for a single call will add more complexity then simply supporting a single API call. Its like putting it heat defeats the "simplicity" benifit of a flat single call.
14:15:26 <enikanorov> sballe: what does mean 'bringing'?
14:15:48 <crc32> present tense for "bring"
14:16:03 <enikanorov> crc32: i think it's the operator's responsibility to choose right tools for automation
14:16:05 <sbalukoff> In any case, we're going to need API which covers manipulating primitives. So for the Rackspace proposal does that. It also tries to solve the single-call problem-- though again, this is not yet well defined.
14:16:17 <obondarev> I doubt that supporting a single API will be 'simple'
14:16:30 <enikanorov> Heat is focused on that. if it's not good enough, you can use neutron client directly to create everything you want
14:17:06 <enikanorov> yeah, another concern is that 'single-call API' is simple from the first glance only
14:17:13 <crc32> enikanorov: Where not talking about automation. Were talking about a simple way to build a loadbalancer with pools and poolmembers. Its more about making the common case simple.
14:17:14 <jorgem> So I am going to link the use cases with walkthroughs to show how this API would work. I think that may ease some confusion
14:17:38 <enikanorov> crc32: common case is well-covered by the UI
14:17:43 <sbalukoff> jorgem: Is there a plan to alter the language used in the API y'all proposed to conform with the teminology defined here?  https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary
14:18:16 <enikanorov> crc32: and btw, that depends on what is 'common'
14:18:31 <rm_work> sbalukoff: what terminology is wrong currently? maybe we need to define "content_switching"? but I am not sure what else would be missing
14:18:33 <crc32> sorry enikanorov but UI is not an API.
14:18:52 <enikanorov> crc32: i'm talking about UX now, how users will consume that
14:18:54 <sballe> crc32: + 1
14:19:16 <sballe> enikanorov: You cannot hide complexity behind the UI.
14:19:17 <sbalukoff> rm_work: The use of the term "load balancer" doesn't seem to work with the glossary. Reading the API, it seems to me that by "load balancer" you mean "listener" as defined in the glossary.
14:19:32 <jorgem> sbalukoff: We were thinking of it from an open-minded perspective so potentially yes. I don't want to be limited to the glossary but also want to keep it in mind.
14:19:39 <sballe> A single API call or higher level API call make sense
14:19:50 <enikanorov> sballe: right, if a use case is complex
14:20:07 <sbalukoff> jorgem: I just know that using two completely different meanings for the same words tends to breed confusion in these discussions.
14:20:18 <jorgem> sbalukoff: Otherwise we could potentially be limiting ourselves to possibilities. Again, we are in the nascent stage of building up a proposal so feedback is most welcome.
14:20:30 <rm_work> sbalukoff: I think yes it is very close to that definition, but there would need to be some changes also (for example it is no longer specifically a child of the VIP object). we could update that but then it would break existing proposals, no?
14:20:36 <crc32> thats why I call them loadbalancer/listeners untill an agreement is arrived at.
14:20:49 <jorgem> sbalukoff: Correct, I'll make sure we add a new glossary specific to this proposal to ease confusion.
14:21:08 <rm_work> sbalukoff: so maybe we just need to set the glossary on hold for a bit, since I think the change is obvious enough that you were able to point it out and I think you understand the difference
14:21:17 <sbalukoff> jorgem: Sounds good to me. As long as you're defining your terms, I don't have a problem with using terms specific to your proposal.
14:21:23 <rm_work> or as jorgem says, maybe a new glossary?
14:21:36 <jorgem> sbalukoff: awesome. Thanks.
14:21:42 <bbaby> From API doc "one port and one protocol per load balancer" - Does that mean one listener can have 'either' tcp Or udp per port?
14:22:19 <jorgem> btw, is anyone else working on a new API proposal? It would be nice to have several to eventually discuss.
14:22:38 <sbalukoff> jorgem: I'm planning on putting one together with my team this week.
14:22:45 <enikanorov> jorgem: another proposals are actually reflected in API discussion
14:22:48 <obondarev> jorgem: we already have several
14:23:00 <enikanorov> jorgem: sorry in Obj Model discussion
14:23:04 <sbalukoff> Though it might not be ready by our next meeting. I'm going to try to have it ready then so we can continue this discussion apace.
14:23:22 <jorgem> enikanorov: So object model doesn't have API calls? Can someone add those?
14:23:22 <enikanorov> there each object directly maps to a resource that can be CRUDed
14:23:31 <enikanorov> jorgem: ^^
14:23:31 <jorgem> enikanorov: Like POST, PUT, DELETE, etc.
14:23:42 <enikanorov> jorgem: that's just implied
14:24:02 <rm_work> enikanorov: i think in this model also, each object directly maps to a resource that be CRUDed
14:24:03 <jorgem> enikanorov: Correct, perhaps walkthroughs to see if the proposals satisfy the requirements everyone has layed out?
14:24:05 <german_> well, let's make it explicit
14:24:11 <sballe> jorgem: We like the ATLAS' type approach since that s what we are currently using for our production lBaas so we won't come up with a new proposal but comment and help improve yours
14:24:14 <rm_work> enikanorov: unless i am missing something
14:24:16 <sbalukoff> enikanorov: I think the object model discussion probably needs API discussion attached: There's some subtlety involved in, for example, what really happens when you "delete" something.
14:24:33 <german_> +1
14:24:38 <enikanorov> #action enikanorov to add API sketch to Obj Model discussion
14:24:38 <sballe> +1
14:24:46 <markmcclain> rm_work: REST do not have to directly map the object model
14:24:54 <sbalukoff> Oh! I forgot about those...
14:25:01 <markmcclain> there are valid reasons not to have them maop
14:25:06 <sbalukoff> #action sbalukoff to propose alternate API
14:25:07 <markmcclain> s/maop/map/
14:25:21 <rm_work> markmcclain: they don't have to, but in this case enikanorov is complaining that they should, and i am pointing out that they DO
14:25:32 <rm_work> markmcclain: so I am trying to figure out his complain :)
14:25:43 <rm_work> *complaint
14:25:50 <enikanorov> i'm saying that in the obj model proposals objects map to API
14:26:23 <enikanorov> i'll make it more explicit
14:26:26 <rm_work> referring to: <enikanorov>	 there each object directly maps to a resource that can be CRUDed
14:26:27 <blogan> so is the main contention here the single api call or the api definition itself?
14:26:34 <rm_work> unless i misunderstood what you were saying
14:26:40 <crc32> I don't know. Some of thhese objects don't arn't normalized so its not obvious which is the root object. That makes the actual API spec ambigous.
14:26:42 <rm_work> in that case, please ignore and continue
14:26:43 <enikanorov> rm_work: "there" means in the proposals we have
14:27:15 <rm_work> enikanorov: which are what you seem to be advocating?
14:27:20 <enikanorov> crc32: right. that's why 'root object' definition lays in object model, not in the API
14:27:44 <rm_work> enikanorov: i thought we agreed in a past meeting that the object model should fall out of the API definition, and not the other way around
14:27:45 <crc32> so I see multiple ways to interpret the API based on the object models so I think there is a great benifit to show what concrete API calls would look like.
14:27:47 <enikanorov> rm_work: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion has 4 proposals
14:27:58 <enikanorov> i'm advocating #2 and #3
14:28:18 <sballe> rm_work: +1 I am confused too on how we proceed.
14:28:46 <blogan> weren't we supposed to first discuss the API and decide on that first before we even start talking about the object model?
14:28:53 <blogan> if the API model works the object model will fall into place
14:29:01 <jorgem> enikanorov:  I thought markmcclain wanted us to work on API discussion. object model discussion to me is the internal domain that may or may not map to the API 1-to-1
14:29:04 <sballe> blogan: That was my understanding too
14:29:18 <jorgem> markmcclain: thoughts?
14:29:27 <sbalukoff> I'm sort of in the same boat (I think) as enikanorov here: I see API and object model being intricately linked.
14:29:40 <enikanorov> right
14:29:45 <sbalukoff> It doesn't make a whole lot of sense to discuss API without some idea of what the underlying object model looks like.
14:29:50 <enikanorov> starting from API is also ok
14:30:05 <enikanorov> it's just happened that we were discussion in terms of obj model
14:30:06 <rm_work> sbalukoff: i think they are too -- but in a cause -> effect sort of way; define what you want of the API, and it becomes clear what the object model needs to be
14:30:10 <sbalukoff> So maybe--  in proposing API, also present a diagram of what the resulting object model looks like?
14:30:24 <jorgem> sbalukoff: Correct but the object model proposals need to be linked to an actual API. Right now an API can be inferred which can lead to confusion. An explicit API would be nice so that we may compare.
14:30:29 <sbalukoff> rm_work: Yeah, I'm fine with that, too.
14:30:32 <rm_work> I actually thought we had one, I am not sure what happened to it, as it is not in that document…
14:30:41 <sbalukoff> jorgem: Agreed!
14:30:43 <enikanorov> jorgem: i'll add explicit API
14:30:55 <blogan> sbalukoff: id say the object model doesn't matter very much when it comes to the API because once the API schema is defined, the object model should be obvious
14:30:57 <rm_work> blogan: didn't you show me an object model that was derived from that API def?
14:30:58 <jorgem> enikanorov: To all 4 proposals?
14:31:02 <crc32> sbalukoff: I believe the API depends on the object model but I don't think that means the object models proposed have a 1 to 1 relation ship with the API. For example the L7Association what would a call to add that look like in the REST tree?
14:31:17 <crc32> what would the call that actually joins objects together look like?
14:31:23 <enikanorov> jorgem: for the first 3, i guess, they are not very different
14:31:26 <sbalukoff> blogan: I still want my pretty pictures. :)
14:31:35 <blogan> rm_work: is was just a diagram of the API not the object model, though the object model would be similar
14:31:47 <jorgem> enikanorov: Sounds good just want to make sure we have something for all proposals in order to compare fairly
14:32:12 <enikanorov> jorgem: the thing is that comparison will go down to obj model
14:32:24 <enikanorov> because it still has 1-1 mapping with the API
14:32:36 <sbalukoff> enikanorov: Not necessarily 1-1
14:32:57 <blogan> sbalukoff: I like pretty pictures too :)
14:32:58 <sbalukoff> But yes, I think an API discussion is incomplete without knowing what the resulting object model will look like.
14:32:58 <enikanorov> yeah, not necessarily, but for most of the objects
14:33:08 <jorgem> enikanorov: I disagree. The API is how users will interact with the service. The object model may not be a 1-to-1 mapping. In CAN be but isn't required.
14:33:33 <enikanorov> jorgem: you are right, it's not required
14:33:41 <jorgem> enikanorov: As long as the API satisfies everyone's use cases then we should all be happy right?
14:33:42 <crc32> enikanorov: so what would # 2 look like. "POST /vip/loadbalancer/Pools" {"members":[…]}?
14:33:49 <enikanorov> we have general constraints like those i mentioned in the beginning
14:34:04 <enikanorov> and then we just have to decide 'first class citizens' of the API
14:34:26 <enikanorov> it then lead to 1-1 mapping for most of obj model objects
14:34:36 <enikanorov> jorgem: yep!
14:34:39 <jorgem> enikanorov: I guess I'd like to understand this constraints a little better so that I don't go down the wrong path then.
14:34:41 <crc32> would there be a call like "PUT /loadbalancer/someuuid/attach_member/{member_uuid}"
14:35:14 <jorgem> markmcclain: What constraints do we have in making a new API?
14:35:16 <enikanorov> jorgem: i think looking at Neutron API will help with that
14:35:26 <obondarev> seems we just need to have both API calls and object model in each proposal so everybody would be happy
14:35:31 <markmcclain> jorgem: honestly we don't have any
14:35:32 <enikanorov> what it usually does, and what it doesn't do
14:35:51 <markmcclain> talking with other large deployers the common response is folks want something that works
14:35:58 <sbalukoff> markmcclain: Other that "don't do stupid things?" ;)
14:36:28 <blogan> hopefully somethign that just works and something that doesn't cause confusion
14:36:38 <sbalukoff> blogan: Indeed!
14:36:59 <markmcclain> right we also have to be careful to remember that some of the larger users of loadbalancing do much more than http(s)
14:37:01 <german_> I think adding some examples will help avoid confusion
14:37:02 <crc32> I think we need something more concrete,
14:37:03 <jorgem> enikanorov: From your perspective what constraints are there? I'd like to keep them in mind when working on the API proposals
14:37:39 <enikanorov> jorgem: doing same thing with several ways is one of such (at least, to think of it before actually implementing another way)
14:38:28 <sbalukoff> enikanorov: That kind of vetoes the whole "single call" discussion, which I'm not sure is fair.
14:38:44 <blogan> we can definitely put together an object model for this API but we were hoping to get the community's ideas on tweaks that could be done before we started drafting the object model
14:38:47 <jorgem> enikanorov: so multiple calls vs single call I'm guessing? This as discussed last week would be a choice.
14:38:53 <crc32> yea seems like that constraint was made up on the fly. lol
14:39:09 <jorgem> enikanorov: Let me work on this a little more in the following week. I think I can convince you.
14:39:20 <enikanorov> another constraint is consistency
14:39:54 <german_> what do you mean by that?
14:40:01 <sballe> enikanorov: Can you elaborate on consistency?
14:40:23 <enikanorov> as i said, if we go with single-call, than everything should be possible with that single call
14:40:30 <enikanorov> no 'support calls'
14:40:35 <crc32> enikonorov: Meaning consistency for the neutron api and thats the only Argument I'm taking into consideration. I'm waying the needs of our customers with the need to look consistent with neutron.
14:40:39 <enikanorov> otherwise it would be just no point in in
14:40:46 <rm_work> enikanorov: are there any proposals that violate that?
14:40:47 <enikanorov> *it
14:41:01 <crc32> not ours.
14:41:17 <enikanorov> rm_work: it's just that existing proposal is not capable for that yet
14:41:30 <blogan> enikanorov: how so?
14:41:34 <rm_work> enikanorov: the proposal that jorge made *is* capable of that, unless I am missing something
14:42:08 <crc32> but I don't agree with the premise "If it doesn't support all complex cases there for lets junk the whole concept of a single API call".
14:42:20 <german_> +1
14:42:27 <enikanorov> it will, when we resolve how to deal with arbitrary object graph within a json
14:42:39 <german_> I am happy when 90% of cases can be covered by a single call
14:42:57 <rm_work> enikanorov: i think there was actually a section covering this, unless I am mistaken...
14:43:03 <enikanorov> crc32: i'm not 'junking' it, i would just like to see it in its completeness
14:43:13 <sbalukoff> crc32: Right. But, we don't know what the simple case being asked for looks like. I'd like those who are looking for "single call" functionality to elaborate on that (some examples would really help here!)
14:44:10 <blogan> rm_work: there wasn't a section on that, well not a explicit section, but I explained it in the ML
14:44:27 <rm_work> blogan: ah, i think your ML response was what I was thinking of
14:45:44 <crc32> Here qre examples of proposed API calls. https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit?pli=1
14:45:44 <obondarev> I'm wondering if single-call api is something that can't be discussed/added as an extension after we agree on the main api (covering all use cases)
14:45:47 <rm_work> actually, i had remembered changing it so the rules were actually defined WITH the pool in question, so we didn't even have to do inter-json references… which was the only place that was happening originally… was that change not included int his proposal?
14:45:50 <blogan> however we should definitely go back to that document and add how all the use cases would be accomplished using the api, an object model, and also probably put it on the wiki since that monolithic text document sucks for navigating to sections
14:46:03 <enikanorov> Q:  Why only one pool per load balancer?
14:46:04 <enikanorov> A:  One pool per load balancer also simplifies everything.
14:46:08 <enikanorov> srsly?
14:46:24 <sbalukoff> obondarev: I think we can do both discussion in parallel, but probably on the ML.
14:46:33 <enikanorov> 1 pool per loadbalancer is already supported right now
14:46:38 <blogan> obondarev: i totally agree with that, it should not be a deal breaker for the api
14:46:39 <rm_work> enikanorov: multiple pools are covered in the content_switching object, with the single pool on the high-level object being the default pool
14:46:58 <enikanorov> if that's what all want, we don't need to even discuss the API
14:47:03 <crc32> enikanorov: Yea I think we could rethink the single pool per loadbalancer.
14:47:34 <crc32> enikanorov: I think they took it out and placed it in content-switching since thats the only place that required one as of now.
14:48:00 <enikanorov> crc32: not really, not the only place
14:48:01 <blogan> enikanorov: if that is a big problem then yes multiple pools can be added but it needs to be well thought out
14:48:16 <enikanorov> pool is merely a group of nodes
14:48:19 <rm_work> enikanorov: we would love feedback on examples of where else having multiple pools would be required
14:48:20 <enikanorov> not more than that
14:48:29 <enikanorov> it's not a loadbalancer
14:48:35 <sbalukoff> enikanorov: Er.. I think it has some other attributes, too.
14:48:39 <rm_work> we literally couldn't think of any cases besides L7 switching
14:48:41 <enikanorov> we can bind it so one, or to two
14:48:42 <bbaby> One port and one protocol simplifies everything - Will this be a problem for dns vips as it uses both tcp and udp
14:48:46 <german_> we need to map some of our use cases to the APi to understand if everyhting is supported
14:49:11 <rm_work> bbaby: i think typically "TCP_AND_UDP" together is defined as a protocol?
14:49:18 <sbalukoff> bbaby: Careful-- they're using 'load balancer' to mean something not discussed in this list.
14:49:20 <rm_work> someone else can correct me if that is wrong
14:49:52 <blogan> bbaby if that is required another load balancer can share the same vip and use the same port as long as one is tcp and the other is udp
14:49:58 <sbalukoff> german_: That would be helpful, too!
14:50:08 <rm_work> blogan: ah, is that how we take care of that use case?
14:50:10 <blogan> baby: or what rm_work said
14:50:13 <sbalukoff> blogan: Again, please define 'load balancer' before going down this rabbit hole.
14:50:28 <enikanorov> rm_work: why to think about the cases beside l7 switching?
14:50:33 <rm_work> sbalukoff: i don't know how that term causes so much confusion? but we will do so
14:50:42 <enikanorov> rm_work: are you putting L7 out of roadmap?
14:50:48 <blogan> sbalukoff: load balancer being defined as how this api proposal uses it
14:50:51 <rm_work> enikanorov: no! it is specifically handled there
14:51:05 <sbalukoff> rm_work: It causes confusion because we've being using it to mean something else for the several weeks we've been having this discussion here. :)
14:51:14 <rm_work> enikanorov: so then, why ELSE would we need multiple pools? if L7 switching is the only reason, then the definition as it is takes care of that requirement
14:51:24 <sbalukoff> rm_work: This actually was the main reason we put together that glossary page!
14:51:42 <rm_work> sbalukoff: i mean, a load balancer is a load balancer. what else does it mean? use the definition from dictionary.com?
14:51:51 <rm_work> i don't think we use it any different
14:51:53 <german_> listener :-)
14:52:14 <enikanorov> rm_work: so, the thing is that pool is just a pool, not a two kinds, one in 'default' section and another in 'content-switching'
14:52:33 <rm_work> enikanorov: it is not two different kinds of pool. they are literally the same object type
14:52:36 <enikanorov> pool, say, could be reused potentially by different VIPs
14:52:38 <ptoohill> They are the same thing
14:52:42 <sbalukoff> rm_work: I don't care whose definition you use as long as you define it. There are clearly different things meant with how you're using it versus how this group has been using it.
14:52:56 <enikanorov> i mean that i'd like to define them in the same way
14:53:16 <rm_work> sbalukoff: if that is the case then the group should have defined it before, because my understanding of the term LoadBalancer has not changed in the past year or so
14:53:22 <blogan> i dont think debating about the name load balancer versus listener, or the single api call is the big problems we whould discuss
14:53:35 <blogan> that can be resolved later if this goes forward, if it doesn't then there's no point in debating it
14:53:35 <german_> +1
14:53:43 <rm_work> sbalukoff: so apparently I have been misunderstanding the term loadbalancer as used by this group for the past months
14:53:52 <german_> that
14:53:58 <ptoohill> ditto
14:54:02 <blogan> what enikanorov broguth up about the single pool versus multiple pool should be worth the time for debate
14:54:04 <german_> 's why the glossary came into existence
14:54:09 <crc32> Single API call seems pretty important to me though.
14:54:18 <enikanorov> ok, folks
14:54:19 <sbalukoff> blogan: If we're not using consistent definitions, then this discussion tends to go nowhere. We've had a few months to confirm this and hence a glossary was invented. Do we really need to do it again?
14:54:25 <enikanorov> on slightly different matter
14:54:31 <enikanorov> here's a patch https://review.openstack.org/#/c/72092/
14:54:39 <enikanorov> that implements 'loadbalancer instance'
14:54:52 <enikanorov> I can embed there simple support for 'single call' API
14:55:08 <enikanorov> in fact, it would be simpler than suggested in your doc
14:55:16 <enikanorov> but it still will cover somve simple cases
14:55:21 <rm_work> sbalukoff: well, apparently no one defined loadbalancer on the glossary to begin with, which is an oversight. (I think everyone all assumed their definition was the obvious one). you seem to be using this fact to attack the current proposal specifically....
14:55:31 <rm_work> let's define it on the glossary and move on
14:55:41 <blogan> rm_work: there is a load balancer definition
14:56:02 <rm_work> oh, ok yes, i missed it
14:56:10 <rm_work> …. and the definition there is EXACTLY how we are using it
14:56:14 <rm_work> so i don't see the problem? sbalukoff ?
14:56:41 <german_> let's get some action items
14:56:53 <blogan> rm_work: not exactly, it maps to multiple pools (and ours does with L7 switching), and it maps to multiple ports
14:57:02 <blogan> rm_work: which ours doesn't without creating another load balancer
14:57:03 <rm_work> it doesn't say that necessarily
14:57:05 <enikanorov> rm_work: i believe it was defined in the glossary, no?
14:57:16 <rm_work> "An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc."
14:57:26 <rm_work> it doesn't say "multiple of each" anywhere
14:57:33 <rm_work> just that it has multiple resources, including those
14:57:34 <blogan> rm_work: you may be right
14:57:44 <crc32> sbalukoff: Can you continue to work on the SSL L7 side of the API your advocating. Were pretty flexible and would like to see your ideas. And by ideas could you provide examples of the rest calls and the object model. I agree they are tightly integrated but defining only one side leaves the other side open to interpretation.
14:57:46 <rm_work> and that it is the root object
14:58:13 <sbalukoff> crc32: I'd be happy to!
14:58:18 <rm_work> though I'm not sure why it includes members, since in every definition we've seen, they have been within a pool not directly within the LB
14:59:03 <german_> #action sbalukoff  work on the SSL L7 side of the API
14:59:07 <sbalukoff> rm_work: Agreed, members should be subordinate only to pools.
14:59:11 <rm_work> anyway, sbalukoff if you could expand on how you think we are using the term differently? i really do not understand -- i promise i am not trying to be difficult :(
14:59:19 <enikanorov> #action sbalukoff to prepare API for SSL and L7
14:59:27 <crc32> sbalukoff: it looks like you were thinking of the same thing I was with your concept of front-end back-end certs. I think we should use that instead of DecryptSSL and ReEncryptSSL.
14:59:44 <sbalukoff> rm_work: Looks like I'll have to do that on the mailing list.
14:59:48 <sbalukoff> We're out of time.
14:59:52 <rm_work> sbalukoff: ok :(
14:59:59 <rm_work> I will look for that
15:00:14 <enikanorov> ok folks, we need to wrap up
15:00:19 <obondarev> I'd also like to remind about backward compatibility (which apparently seems not required now but still is a very nice thing to have) while developing new API/object models
15:00:36 <enikanorov> thanks everyone
15:00:37 <jorgem> thanks
15:00:38 <rm_work> and sorry for being half-blind this morning and missing it entirely on my first pass of the page :P
15:00:38 <enikanorov> #endmeeting