14:00:19 <enikanorov_> #startmeeting neutron lbaas
14:00:20 <openstack> Meeting started Thu Apr  3 14:00:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:25 <enikanorov_> hi everyone
14:00:30 <sbalukoff1> Hello!
14:00:30 <sballe> morning :-)
14:00:30 <blogan> hi
14:00:33 <vjay> Hi
14:00:34 <ptoohill> hello
14:00:35 <tvardeman> morning
14:00:40 <obondarev> hi all
14:00:49 <Subha> hi
14:00:57 <edhall> hi
14:00:57 <aburaschi> Hi
14:01:01 <retr0h> hi
14:01:03 <jorgem> hello
14:01:04 <evgenyf> hi
14:01:17 <enikanorov_> glad to see lots of folks here
14:01:18 <marios> hi all
14:01:41 <enikanorov_> let's start with one of the action items from the previous meeting
14:02:06 <enikanorov_> which was collecting cloud operator's data on demanded lb features
14:02:27 <enikanorov_> i've created a wiki page, but it seems that it's not the best way of collecting such kind of data
14:02:40 <enikanorov_> so please lets move to google spreadsheet:
14:02:43 <jorgem> enikanorov: Yeah the google spreadsheet looks better
14:02:53 <sbalukoff> Sounds good.
14:02:56 <retr0h> etherpad?
14:03:00 <enikanorov_> #link https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0
14:03:02 <edhall> good idea
14:03:16 <enikanorov_> it's quite empty at the moment, so please  ...
14:03:39 <sballe> How do you want us to fill it in?
14:03:39 <jorgem> enikanorov_: I added stuff to the requirements page but I'll move it over after the meeting
14:03:55 <sballe> I added stuff to the requirement page too
14:04:10 <sbalukoff> Would you like us to fill out the first column with features we use? And does it make sense to collect data on features already delivered (eg. "Load balance HTTP connections")?
14:04:14 <enikanorov_> jorgem: cool
14:04:54 <enikanorov_> sbalukoff: i think the main idea to know what is demanded from the features that are not there (in lbaas)
14:04:56 <rm_work|away> sbalukoff: I would assume data on ALL features, delivered or not, would be required for a big picture view
14:05:03 <enikanorov_> and since lbaas is very basic right now
14:05:14 <sbalukoff> Ok.
14:05:21 <enikanorov_> it would be almost al features possible
14:05:30 <enikanorov_> *all
14:06:10 <blogan> enikanorov: do you know what the line is between what features we expect neutron lbaas to have and what features an orchestration layer should provide? (i.e.: HA could be provided by the orchestration layer, but not by the driver)
14:06:15 <tvardeman> I would like to see stats on features already delivered.
14:06:30 <jorgem> The groups I have data for so far are: protocol utilization, algorithm utilization, health monitoring utilization, connection logging utilization, ssl term utilization, and content caching utilization
14:06:31 <samuelbercovici> to clarify, you want to move all items from https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements to this spreadsheet?
14:06:37 <enikanorov_> blogan: HA will (and must) be provided by the driver
14:06:49 <blogan> enikanorov: good, thank you
14:06:58 <rm_work> samuelbercovici: i assume just stats?
14:07:04 <enikanorov_> HA is essential feature, pushing it on orchestration level means that we are making user to configure it
14:07:05 <jorgem> samuelbercovici: I was just going to move the operator data
14:07:19 <sballe> enikanorov_, can we revisit the HA by the driver decision? This is a limitation and then we have to implement the same thing for each driver
14:08:00 <enikanorov_> sballe: 'same thing for each driver' is a code reuse issue. drivers actually may want to implement it differently
14:08:01 <samuelbercovici> jorgem: since there is large overlap between tenant and operator, does it make sense to list an item once and then mark whether it relates to tenant, operator or both?
14:08:26 <sbalukoff> sballe: I think some drivers can return a "feature not available" error or something similar for HA configurations which don't work with them?
14:08:35 <jorgem> samuelbercovici: In terms of feature usage?
14:08:40 <sbalukoff> So not every driver needs to deliver the same kind of HA.
14:09:11 <samuelbercovici> jorgem: probably my confusion. the excell is only for operator feature statsitics?
14:09:50 <sbalukoff> samuelbercovici: I would think the spreadsheet is for all features-- but yes, it probably does make sense to distinguish between user and operator features.
14:09:56 <samuelbercovici> btw, to make sure we are clear, does operator mean cloud-operator or tenant-operator? I assume cloud-operator
14:10:00 <sbalukoff> Though, I think the requirements page does this already, too.
14:10:02 <sballe> enikanorov_, so are you saying that if we need to use a pool of standby servers it needs to be part of the driver?
14:10:09 <enikanorov_> samuelbercovici: cloud op
14:10:09 <jorgem> samuelbercovici: Correct. Some features may not be as easy to gather stats on. However, stuff like what percentage of load balancers use SSL term vs not.
14:10:24 <vjay> Yes, HA should be flexible. Today we have code abstracted out of HA proxy agent to be used by other drivers. A similar thing could still happen for HA. But it should be possible for implement driver to implement it in the way it wants.
14:10:25 <enikanorov_> sballe: yes.
14:10:28 <edhall> There is certainly overlap between the two
14:10:33 <aveiga> what about operators that aren't at liberty to share usage data?
14:10:48 <blogan> sballe: i think that makes the most sense right now
14:11:11 <enikanorov_> sballe: if this will be something that is used outside single driver - we can push it to some common place in the code tree so other drivers can reuse it
14:11:15 <sbalukoff> aveiga: We'll have to make decisions without those operators' data, then. :/
14:11:15 <samuelbercovici> sballe: doe you mean HA proxy is highly available or the load balanced application is highly available?
14:11:18 <jorgem> aveiga: This is why we are using relative data not finite numbers
14:11:22 <edhall> Since we're essentially a private cloud, "users" are typically "operators"
14:12:39 <sballe> blogan, maybe short term. I can just see that we should be able to provide the framework at the plug-in level to support this for any sw LB. Maybe introducing the notion of an admin API so we cabn manage the LB service itself
14:12:42 <aburaschi> Do we already have a preferred 'common place' for common code?
14:13:03 <samuelbercovici> sballe: Is "pool of standby servers" related to the servers available to host AH proxy or the application servers load balanced by LBaaS
14:13:15 <sballe> samuelbercovici, I would like the LB service to be resilient
14:13:30 <jorgem> aveiga: We are trying to use data to back up requirement priorities. So if an operator really wants X feature but can't back it up with data then a decision will have to be made without it…which will be harder to accomplish than if the data is present.
14:13:35 <samuelbercovici> sballe: ok thanks
14:13:41 <sballe> the pool is used to make the LBs resilient
14:14:05 <sballe> samuelbercovici, it is really a pool of standby LBs
14:14:05 <jorgem> aveiga: Also, new features will most likely not have data so those will be more open to debate.
14:14:14 <enikanorov_> sballe: until it's something specific to particular driver - it should be implemented there. There could be admin API however to manage that pool
14:14:28 <sballe> enikanorov_, Agreed
14:14:51 <aveiga> jorgem: thanks for the clarification.  I'm trying to get clearance to share, but I can't as of yet
14:15:10 <jorgem> aveiga: No worries, so did I :)
14:15:12 <enikanorov_> ok, if we're done with discussing usage data/requirements, i'd like to move to the other topic
14:15:20 <samuelbercovici> enikanorov_: Assuming this is HA proxy only, than the API is something available from "HA proxy" management system
14:16:03 <enikanorov_> samuelbercovici: initially we have a proposal that any driver that needs something specific for operator, could expose API
14:16:31 <enikanorov_> we had many proposals at icehouse summit, you know :)
14:16:42 <blogan> doesn't that require an extension like behavior for neutron lbaas?
14:16:59 <enikanorov_> blogan: it does, and even a little bit more flexible than that
14:16:59 <blogan> i mean an extension to the neutron lbaas extension
14:17:11 <enikanorov_> it's not extension on extension, btw
14:17:11 <blogan> recursive extensions!
14:17:13 <samuelbercovici> enikanorov_: if this is driver specific, it can be available directly from the driver. we can discuss this in ML.
14:17:42 <enikanorov_> well, we don't have the ability to do 'available directly from the driver'
14:17:52 <enikanorov_> in fact, we already have such admin API
14:17:59 <enikanorov_> which is agent scheduling for haproxy
14:18:06 <enikanorov_> it's embedded into the plugin itself
14:18:08 <enikanorov_> which is not good
14:18:23 <samuelbercovici> enikanorov_: I agree on that
14:18:37 <sballe> enikanorov_, so can we move it up sp it is a framework across all plug-ins?
14:18:41 <enikanorov_> that API could be exposed by haproxy driver, and not be the plugin
14:19:16 <enikanorov_> sballe: yes, the initial proposal was like that. Btw, lbaas is not the only plugin that needs that
14:19:27 <sballe> enikanorov_, agreed,
14:19:44 <sballe> enikanorov_, do you have a blueprint or so I can look at?
14:19:55 <samuelbercovici> sballe: the operator API, UI and capabilities that each vendor provides are difficult to harmonize
14:20:07 <enikanorov_> sballe: yes, we do. i'll find it shortly
14:21:25 <sballe> enikanorov_, thx
14:21:42 <enikanorov_> ok, the next topic i'd like to discuss is API
14:22:02 <enikanorov_> we heard some claims that existing API is confusing/not user friendly
14:22:15 <enikanorov_> so i'd like to make some introduction on this topic first
14:22:31 <jorgem> correct and mark mcclain agreed with that
14:22:44 * sballe I agree too ;-)
14:22:44 <enikanorov_> initially the API was made simplistic to account for the most basic features that every LB solution provides
14:23:01 <enikanorov_> so there was some simplifications all around
14:23:24 <enikanorov_> one of the biggest simplification was that we made 'Pool' object - the root object
14:23:35 <samuelbercovici> it was also required to be made cli friendly
14:23:39 <enikanorov_> e.g. the object with which lb workflow starts
14:23:46 <samuelbercovici> this resulted many 1st level objects
14:23:56 <enikanorov_> 'cli-friedliness' is a must basically
14:24:15 <ptoohill> what does 'cli-friendliness' actually mean?
14:24:35 <jorgem> enikanorov_: Since tenants use the API I think it needs to be catered torward their understanding of load balancing, not operators understanding though
14:24:36 <enikanorov_> ptoohill: it means that user should be able to operate the configuration on per-object basis
14:24:46 <ptoohill> ah, thank you
14:25:00 <tvardeman> +1 jorgem
14:25:07 <enikanorov_> jorgem: well, i agree, the problem is that API is made by mortals (e.g. us) :D
14:25:09 <samuelbercovici> it also means, that cli commands should be reasonably short
14:25:17 <sballe> can we ask a different question? and go top down. What does user friendly mean?
14:25:29 <enikanorov_> sballe: that's a great question
14:25:39 <enikanorov_> and that's why i'd like to hear from you
14:25:42 <sballe> and then figure out if it is even compatible with the model we have now?
14:25:47 <jorgem> sballe: I'll give it a shot...
14:26:09 <sballe> jorgem, ok
14:26:27 <enikanorov_> jorgem: please
14:27:04 <ptoohill> so, in that case, a single populated object (one call, not many) is not cli-friendly?
14:27:21 <jorgem> sballe: From our perspective we have a bunch of tenants that know they need load balancing but don't exactly understand networking at a low level. The goal for us is to make simple enough so that a first time web developer (for example) can configure their own lb but have the features that a power user would need as well.
14:27:33 <german_> +1
14:27:34 <enikanorov_> ptoohill: single call could be an extra, but not the whole API
14:27:59 <aburaschi> +1
14:28:01 <ptoohill> well of course, but to have all the features contained in the single object sounds friendly to me
14:28:06 <jorgem> jorgem: That's kind of it in a nutshell. ML might be better for this though
14:28:06 <ptoohill> then being able to modify those individually
14:28:10 <enikanorov_> single call has one huuuuge issue
14:28:19 <tvardeman> ptoohill: maybe not "all" but "many"
14:28:22 <sbalukoff> In other words, make the API have good defaults so a novice user can configure services, but provide enough optional arguments to a power user isn't hindered.
14:28:27 <sballe> jorgem, +1 very similar to our usecase. We also want the user not to worry about managing the LB so it needs to self-manage.
14:28:35 <jorgem> We spent a lot of time on the Atlas API with this in mind.
14:28:48 <aburaschi> Would that also mean a bunch of predefined default settings that suit the purpose of the lb?
14:28:55 <rm_work> sbalukoff: +1, that's what I've been trying to get across -- sane defaults
14:29:03 <enikanorov_> ok, let me answer these
14:29:05 <ptoohill> +1 sbalukoff
14:29:10 <jorgem> BTW our customers love our API in comparison to AWS (they actually state this to us)
14:29:13 <crc32> enikanorov_: It would be hard to do everything in one call if we don't have a lb object to pass in to the api complete with backend nodes.
14:29:31 <enikanorov_> 1. neutron API is quite low-level. it's not an orchestration level
14:29:32 <sballe> I agree that the Atlas API is a starting point and is the reason that we built LIbra using this API.
14:29:44 <enikanorov_> 2. single call-api is not as simple as it seems
14:29:46 <jorgem> however, it needs work to accomodate new items such as pools
14:29:51 <aburaschi> sballukoff: +1
14:29:56 <enikanorov_> we already do have single call API which is Heat
14:30:15 <enikanorov_> and it has one important feature
14:30:32 <rm_work> enikanorov_: that is my question in a nutshell -- what do we delegate to Heat and what is actually done in N-LBaaS API?
14:30:40 <enikanorov_> id requires you to use it's own definition language
14:30:49 <enikanorov_> *it
14:30:56 <crc32> enikanorov_: Heat is a seperate product is it not? Has the desision to pass off everything involving a single call API already getting stamped "We have heat for that"?
14:31:14 <enikanorov_> and the definition language is required (generally) to work with a graph of objects in a single call
14:31:31 <enikanorov_> crc32: Heat is separate orchestration project
14:31:54 <iwamoto> neutron should provide minimal usability without heat.
14:32:08 <rm_work> So, Heat is used to create whole LB configs as a Fire-and-forget sort of thing, and then the user goes and tweaks the LBs in the N-LBaaS API from then on?
14:32:12 <enikanorov_> crc32: the reason to not having single call is technical, not only because 'Heat already has that'. but that as well
14:32:32 <jorgem> orchestrating the configuration of a lb is one thing. Orchestrating the creation/deletion of many lbs is another
14:32:39 <enikanorov_> rm_work: that's one of the options
14:32:41 <sballe> jorgem, +1
14:32:43 <rm_work> jorgem: +1
14:32:49 <sbalukoff> Regarding orchestration, could someone clarify this for me? Shouldn't the API have all the features exposed in it that an orchestration layer would use (regardless of whether it's Heat or something else-- like something a tenant might home grow)?  In other words, there shouldn't be features that are *only* available in Heat, right?
14:33:00 <rm_work> I don't think Heat is the place to orchestrate the creation of a single LB
14:33:10 <sbalukoff> (That would require Heat to manipulate things that aren't in the API, right?)
14:33:19 <aveiga> sbalukoff: +1
14:33:25 <tvardeman> sbalukoff: + 1
14:33:38 <sballe> sbalukoff, +1
14:34:19 <tvardeman> enikanorov_: I think one thing to keep in mind is we're not talking about ease of implementation for one call, we're talking about the user-experience.
14:34:23 <enikanorov_> rm_work: so LBaaS API is not fo orchestraction, but for fine grained conrtol over load balancing function
14:34:25 <rm_work> sbalukoff: I don't think he's saying that all of the features wouldn't be exposed, just that the "single-call" approach would be best done in Heat (define the LB in Heat's language, and have Heat do the 3-4 calls necessary for creation)
14:34:47 <jorgem> sbalukoff: Correct, thus neutron lbaas API exposes everything for managing individual lbs. Heat would be used to manage lbs in concert with other items such as nova (for example autoscaling)
14:34:49 <sbalukoff> rm_work: Ok, yes, I can get behind that. :)
14:34:55 <rm_work> enikanorov_: yeah, but I don't think "create one full LB" falls into "orchestration"
14:35:01 <enikanorov_> tvardeman: one call doesn't allow you to create rich configuration unless you introduce template language like in heat
14:35:25 <sbalukoff> rm_work: +1
14:35:25 <aveiga> shouldn't "one call" be enough to instantiate a ddefault LB though?
14:35:25 <sballe> jorgem, I agree,
14:35:30 <rm_work> enikanorov_: it does if you have sane defaults, aka what sbalukoff was saying earlier
14:35:38 <samuelbercovici> rm_work: I think the term LB is oveloaded
14:35:41 <enikanorov_> rm_work: not really
14:35:44 <crc32> enikanorov_: If nuetron/lbaas is only allowing manipulation of simple primitive objects then I get the feeling our product managers are going to bring up the "Our customers want you to wrap up the api into something simular to the atlas api. I can already hear it now.
14:35:46 <enikanorov_> it's not about defaults
14:35:49 <blogan_> so to create a load balancer a user will instead go through Heat and not Load Balancing as  a Service? how is that not confusing to a user?
14:35:59 <marios> rm_work: but it could do... eg you have a heat template defining your 2/3 web servers and the single load balancer for them.heat brings it all up
14:36:01 <enikanorov_> it's about ability to reference different objects within the configuration
14:36:03 <sbalukoff> samuelbercovici: Yep, I think we're confusing terms again here.
14:36:17 <enikanorov_> the thing is that we don't have a single example of such APIs yet
14:36:29 <rm_work> marios: yeah, I can see what you mean there… in that case it's part of a greater whole
14:36:33 <enikanorov_> none of the lbaas APIs available provides features set we desire
14:36:36 <edhall> so, the API needs to both support (1) simple user interactions and (2) straightforward automation of complex operations. Those are two sometimeds conflicting goals...
14:36:41 <jorgem> enikanorov_: Our current API does allow us to create a rich configuration in one call. However, you can also make several calls to accomplish the same thing.
14:36:59 <jorgem> enikanorov_: That's one of the joys of an asynchronous API
14:37:00 <enikanorov_> jorgem: can you give a link to API reference?
14:37:06 <jorgem> sure one sec
14:37:14 <enikanorov_> and it's not about asyncness
14:37:35 <jorgem> #link	http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Create_Load_Balancer-d1e1635.html
14:37:51 <rm_work> I still believe it comes back to sane defaults, and having a high level object that can be used to define everything necessary to get the LB spun up
14:38:03 <enikanorov_> jorgem: yesh, i've seen this page
14:38:12 <enikanorov_> sorry, this API doesn't fit our requirements
14:38:22 <jorgem> enikanorov_: That's for our current API. The only item is that SSL term must be made in a separate call. Other than that you can add all config in one POST call
14:38:22 <enikanorov_> because it doesn't support multiple pools
14:38:24 <rm_work> I mean, what "<X>aaS" product doesn't have <X> as a high level object...
14:38:29 <enikanorov_> (needed for L7)
14:38:49 <blogan_> enikanorov: that can easily be accomplished with that api though
14:38:52 <jorgem> enikanorov_: Right I was just stating that one call can take in a rich config, not necesarily to use this API
14:38:54 <german_> and here is the libra API for another example: http://api-docs.test.devex.uswest.hpcloud.net/api/lbaas/
14:38:59 <rm_work> enikanorov_: I think that could be solved… it only doesn't support that because it was never a req
14:39:01 <blogan_> enikanorov: i mean with modification
14:39:08 <crc32> I get the whole "provide primitives not solutions" principle but this api is already very high level and it a logical loadbalancing model has already worked well for us at rackspace.
14:39:15 <sballe> enikanorov_, we can tweek the APIs to support the more advnaced features
14:39:31 <tvardeman> enikanorov_: I think the point to take from that is the API request structure, not to mock the current Neutron LBaaS after this api.
14:39:33 <enikanorov_> jorgem: i'm saying that will not be rich enough... i think if we are to go fo a single call - we need to support all features
14:39:51 <enikanorov_> sballe: we can. it would be Heat API
14:40:00 <jorgem> enikanorov_: correct and I think this can be accomplished
14:40:06 <sballe> crc32, +1 same for us. the high level API really works well
14:40:24 <ptoohill> 'here, here'
14:40:25 <enikanorov_> jorgem: this can be accomplished, but it's strongly an 'extra' feature
14:40:28 <crc32> enikamprov_: Punting this off to heat is going to complicate something that belongs in the core api.
14:40:31 <jorgem> perhaps ML discussion so we can get in our points?
14:40:38 <rm_work> enikanorov_: well, i don't know if there is a specific reason to not do all of the 90% use-case features in one call, and have the rest in subsequent calls on an already "UP" loadbalancer
14:40:50 <german_> +1
14:40:58 <german_> I like the idea of being able to tweak
14:41:11 <enikanorov_> crc32: i'm not saying 'putting this off to heat', i'm saying that in order to satisfy our requirements, we need to make the same kind of API as Heat has
14:41:15 <sbalukoff> sballe, jorgem, crc32: Do your organizations use an orchestration layer? Maybe the reason for high-level API is because no such beast exists in your environments?
14:41:21 <tvardeman> +1 rm_work
14:41:35 <jorgem> sbalukoff: Yes we do
14:41:35 <blogan_> i just dont see how passing off the creation of a load balancer to another product is not confusing to a user
14:41:43 <marios> enikanorov_: do you mean in terms of passing in the required configuration + options (ala heat templates)
14:41:51 <jorgem> sbalukoff: Autoscaling is one for example
14:41:57 <rm_work> one of the reasons we are getting all of the use-case statistics together I think is so we can focus on coding for the 95% not the 5%
14:41:59 <samuelbercovici> to clarify, do any of the Rackspace, HP cloud, other , users use cli calls?
14:42:01 <sballe> blogan_, +1 I totally agree
14:42:01 <sbalukoff> jorgem: Ok, so you don't force your users to use orchestration for high-level calls, then?
14:42:11 <enikanorov_> rm_work: no specific reason, other than we are focused on particular objects and fine-grained management, single call mabe added to API as an extra
14:42:21 <rm_work> not that we can't allow the 5% to do their thing, but it shouldn't be the main focus for the API as far as "ease of use"
14:42:22 <jorgem> sbalukoff: We do not
14:42:27 <enikanorov_> marios: yes, it must be a template.
14:42:44 <sbalukoff> Got it.
14:42:49 <samuelbercovici> Do he Rackspace, HP cloud, other , users use cli calls?
14:42:53 <rm_work> samuelbercovici: Rackspace has a CLB CLI
14:42:57 <sbalukoff> Again, many ways to skin the cat, I guess.
14:42:58 <crc32> sbalukoff: Not traditionally. An orchastration layer was added later on for customers that wanted auto scalling built in. But know one uses the orchistration api. The control panel uses it (Since they are UI developers) but I'm not aware of any actual end users using the API.
14:43:08 <jorgem> sbalukoff: Another example of orcestration is when tenants are marked as delinquent and we need to remove their instances across all products.
14:43:08 <marios> enikanorov_: to be clear, the 'single call api' - is this 'in addition to' or 'instead of' the current API?
14:43:20 <samuelbercovici> rm_work: but is it wildly used?
14:43:23 <enikanorov_> marios: an addition, only
14:43:29 <marios> enikanorov_: ack, tx
14:43:31 <sballe> samuelbercovici, we have a cli for Libra
14:43:37 <rm_work> samuelbercovici: 90%+ of our LBs are created through webGUI I think :/
14:43:39 <enikanorov_> marios: that comes from cli requirement and that follows neutron ideology
14:44:03 <crc32> marios: Yes but a single call api would need to beable to support a complex loadbalancer object that contains a list of backend nodes.
14:44:07 <enikanorov_> rm_work: if it's web gui - than user experience goes from gui, not lbaas API
14:44:18 <samuelbercovici> rm_work: in this case, what would it matter if there was a single page to configure LBaaS driving multiple LBaaS calls?
14:44:32 <german_> samuelbercovici we have cli calls and some users have orchestration with ansible, chef, etc.
14:44:33 <rm_work> enikanorov_: yeah, i'm thinking maybe it's not worth arguing this, and we're just going to end up making a GUI layer anyway
14:44:37 <crc32> marios: So it seem odd to have 2 loadbalancer objects. One simple for the primitive operatiopns and one for a complete loadbalancer.
14:44:55 <blogan_> rm_work: horizon already does this methinks
14:45:09 <rm_work> ah, yes, horizon
14:45:09 <enikanorov_> rm_work: yes. anyway those who pass jsons, make it from scripts, not manually
14:45:10 <german_> crc32 +1
14:45:12 <jorgem> rm_work: Correct but we do have the power API users as well
14:45:22 <samuelbercovici> german_: cli that has many many parameters and can encompass multiple lines is ususaly an issue with human users
14:45:25 <marios> crc32: i imagined (and i *think* this is what enikanorov_ is suggesting) that the single call API would be kind of a wrapper around the individual API calls (hence the 'orchestration' bit)
14:45:35 <rm_work> jorgem: yeah, but the power API users could probably handle a "no single-call creation" system
14:45:40 <samuelbercovici> this is why I am asking whether users are using the cli in your environments
14:45:41 <sballe> samuelbercovici, that why we need good defaults
14:45:42 <enikanorov_> marios: not really...
14:45:45 <marios> crc32: so you'd still have the same lb object. just the creation is different?
14:45:47 <rm_work> or would like it just as much, since they're the 5% i was talking about
14:45:49 <german_> yesm we also have horizon we just offer everyhting
14:45:50 <marios> enikanorov_: ah, ok...
14:45:51 <sbalukoff> Ultimately, a GUI is going to be using API on its back-end. :/
14:45:54 <enikanorov_> marios: it can't be a wrapper, i'd say
14:46:14 <rm_work> samuelbercovici: I think that was a very good question
14:46:29 <blogan_> enikanorov: another problem with having all these separate calls is the more you add, the longer it takes to actually spin up a load balancer, granted right now its negligible but in the future it may not be the case
14:46:35 <crc32> marios: Meaning another api that makes lower level apis? Or are we talking about a core api that has the notion of a complex loadbalancer object so that it can be constructed in one call.
14:46:43 <jorgem> rm_work: Why are we stuck on "one single call"? The point is that lbs get configured. One call is nice to pass in all config but that does not preclude from having the option to use several calls. This is what we currently do.
14:46:49 <rm_work> samuelbercovici: and now I am rethinking whether I honestly care what the API looks like or not, since 90% of my users won't ever see it, and the ones that do ARE the power users so I shouldn't be worried about them getting confused <_<
14:46:52 <marios> crc32: well the latter i think
14:47:03 <marios> crc32: but i am new here :) so ...
14:47:06 <enikanorov_> blogan_: just to clarify, i'm not against 'single call' API, but i'm agains making it a primary one
14:47:15 <german_> rm_work, it;s the same for us
14:47:27 <sbalukoff> jorgem: +1
14:47:41 <samuelbercovici> blogan: a way to configure a large object tree, would be to "batch" multiple calls together and then execute whne done
14:47:43 <rm_work> jorgem: i don't think I am anymore <_<
14:48:10 <blogan_> you mean the api batches them together?
14:48:17 <samuelbercovici> this leaves the notion of multiple short api calls but allows to populate an object graph before actually amking a call
14:48:21 <jorgem> Correct, I vote for having one call with the option to also use several calls. If you prefer one over the other then that's your choice.
14:48:21 <german_> I would assume the orchestration layer does
14:48:23 <crc32> enikanorov_: So I ask would this be in the same api (Single call api) or are you advocating an external api (Single call api) that makes multiple primitive lower api calls(The core). I'd like to see a single API that is compatible with both philosophies.
14:48:27 <enikanorov_> jorgem: one one call vs several calls: i think we also need to have consistent api. if we allow to update particular object, we need to allow to create it, e.g. have full set of particular calls
14:48:37 <jorgem> It really shouldn't be hard to implement unless I am missing something
14:49:04 <jorgem> enikanorov_: I agree. sub resources in a RESTful API are nice
14:49:07 <enikanorov_> crc32: i'm not against adding single call to lbaas API as an extra
14:49:18 <samuelbercovici> blogan_: I will send some examples on ML
14:49:20 <enikanorov_> crc32: Heat has it's drawbacks
14:49:31 <marios> enikanorov_: do we have any concrete suggestions on how the 'keep existing API and add the single-call LB create' looks like? or is this first time we are discussing?
14:49:34 <blogan_> samuelbercovici: ok thanks
14:49:40 <enikanorov_> crc32: but the thing is that single-call API would not be a simple json call
14:49:45 <german_> yeah, we need to keep it possible so users can use other orchestration software
14:49:50 <enikanorov_> crc32: it will require template language
14:50:28 <sbalukoff> marios: For Juno, I'd argue for scrapping the existing API (or versioning it) and going with something entirely new that doesn't assume "pool" is the root object. :)
14:50:38 <enikanorov_> marios: the suggestion is to think of how to provide a graph of object in a configuration, that's the technical matter of the question
14:50:39 <crc32> enikanorov_: Can we add the ability for a single api to make multiple primitive calls as well as one single complex call. Thats what we are striving for four our end api users here at rackspace.
14:50:40 <german_> enikanorov_, as long as we only create one lb I am not sure we need some template language
14:50:47 <tvardeman> sbalukoff: +1
14:51:02 <enikanorov_> german_: that's not about 1 lb
14:51:03 <crc32> enikanorov_: I mean add it as a requirement that the api should support both.
14:51:21 <enikanorov_> german_: 1 lb may have several vips and several pools. thea are cross-referenced in configuration
14:51:27 <samuelbercovici> can we do the following: 1. I will define two use cases a simple web based and c omplext multi poools, l7 use case. We can then discuss how those could look from an API perspective using 1. call per item 2. sincale call 3. "batch" call
14:51:27 <sbalukoff> This implies a different work-flow for using advanced features, and I'm OK with this. :)
14:51:30 <enikanorov_> german_: that's what template language is for
14:51:34 <jorgem> Possible action item for new API proposols???
14:51:46 <enikanorov_> samuelbercovici: good suggestion
14:52:01 <sballe> samuelbercovici, +1
14:52:07 <enikanorov_> in fact we've already done that in recen obj model discussion :)
14:52:23 <retr0h> samuelbercovici: +
14:52:24 <aburaschi> It sounds that every single call should consider sane defaults as a basis, right?
14:52:25 <marios> samuelbercovici: jorgem: +1 i think we need to have specific 'thing' to discuss/approve/shoot down.
14:52:44 <enikanorov_> aburaschi: what do you mean?
14:52:50 <sbalukoff> enikanorov_: In a round-about way, yes. I don't think we've actually discussed what the web GUI would look like.
14:53:12 <enikanorov_> web gui is out of scope, definitely
14:53:19 <sballe> marios, +1
14:53:23 <blogan_> enikanorov: how are decisions made? is it all by core reviewers? is it majority rules? committers only?
14:53:52 <sbalukoff> Oh! Sorry, I misunderstood what samuelbercovici suggested.
14:53:55 <enikanorov_> blogan_: that's a hard question...
14:54:06 <crc32> oh wow. Are heat templates yaml files or is it an actual language with a grammer and such forth.
14:54:08 <crc32> ?
14:54:18 <samuelbercovici> on web UI, can we have a google doc in which each web ui implementation will put a few screen captures of their Web?
14:54:20 <aburaschi> enikanorov_: I'm thinking that one way or another, batch or multiple calls will make good use of defaults that consider a complete up lb.
14:54:39 <enikanorov_> crc32: it is. we need particular feature from that language
14:55:02 <marios> crc32: i've only ever seen yaml templates. but there is definitely a grammar that is parsed by the heat engine
14:55:05 <enikanorov_> aburaschi: still not sure i get your question
14:55:38 <samuelbercovici> even if web UI are out of scope, they may represent how users visualize the configuration
14:55:49 <marios> crc32: until recently this was all CloudFormation compatible (aws). the HOT spec is new http://docs.openstack.org/developer/heat/template_guide/hot_spec.html
14:56:20 <crc32> enikanorov_: Which is it YAML or an actual language. Unless I'm mistaken I'm not sure how we can realisitcly right a wrapper api in YAML.
14:56:20 <samuelbercovici> and could be used as another sanity check for the api as obviously the web use consumes the api
14:56:58 <sbalukoff> samuelbercovici: That's a good point. I'm glad I misunderstood your suggestion above, in retrospect. :D
14:57:02 <crc32> thats right up their with writing a DSL in XML and yes we've had the torture of doing that. :(
14:57:10 <enikanorov_> crc32: the feature we need - naming/referencing the objects within provided json. basically that creates such json a separate language for which we will need to create a parser
14:57:13 <marios> crc32: yaml files, where individual tags within have specific meaning/action
14:57:20 <enikanorov_> crc32: not a very big deal, but a thing to consider
14:57:45 <marios> crc32: (fyi example templates that tripleo uses @ https://github.com/openstack/tripleo-heat-templates)
14:58:15 <jorgem> enikanorov_: Before meeting ends do we have proper action items lined out?
14:58:18 <aburaschi> enikanorov_: just thinking that old simple calls should include the defaults that can create a full up lb from an orchestration point of view. maybe this is trivial... never mind :)
14:58:33 <samuelbercovici> so: 1. I will send a google doc with 2 use cases and we can see how each approach works for them 2. on the same document, we can place a few screen captures web UIs
14:58:34 <enikanorov_> jorgem: i'll send them after the meeting shortly
14:59:04 <jorgem> enikanorov_: thanks
14:59:05 <enikanorov_> samuelbercovici: may be i'd separate web ui discussion...
14:59:17 <tvardeman> +1 enikanorov_
14:59:23 <samuelbercovici> enikanorov_: ok. will do
14:59:41 <rm_work> yeah that is a weird case, because it is related, but really "not our problem" right now
15:00:03 <jorgem> rm_work: GUI creators will be big API users though
15:00:03 <enikanorov_> ok, thanks everyone for joining, lets wrap up and continue in ML
15:00:13 <sbalukoff> They will.
15:00:17 <aburaschi> thank you
15:00:17 <enikanorov_> #endmeeting