14:00:19 #startmeeting neutron lbaas 14:00:20 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 The meeting name has been set to 'neutron_lbaas' 14:00:25 hi everyone 14:00:30 Hello! 14:00:30 morning :-) 14:00:30 hi 14:00:33 Hi 14:00:34 hello 14:00:35 morning 14:00:40 hi all 14:00:49 hi 14:00:57 hi 14:00:57 Hi 14:01:01 hi 14:01:03 hello 14:01:04 hi 14:01:17 glad to see lots of folks here 14:01:18 hi all 14:01:41 let's start with one of the action items from the previous meeting 14:02:06 which was collecting cloud operator's data on demanded lb features 14:02:27 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 so please lets move to google spreadsheet: 14:02:43 enikanorov: Yeah the google spreadsheet looks better 14:02:53 Sounds good. 14:02:56 etherpad? 14:03:00 #link https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0 14:03:02 good idea 14:03:16 it's quite empty at the moment, so please ... 14:03:39 How do you want us to fill it in? 14:03:39 enikanorov_: I added stuff to the requirements page but I'll move it over after the meeting 14:03:55 I added stuff to the requirement page too 14:04:10 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 jorgem: cool 14:04:54 sbalukoff: i think the main idea to know what is demanded from the features that are not there (in lbaas) 14:04:56 sbalukoff: I would assume data on ALL features, delivered or not, would be required for a big picture view 14:05:03 and since lbaas is very basic right now 14:05:14 Ok. 14:05:21 it would be almost al features possible 14:05:30 *all 14:06:10 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 I would like to see stats on features already delivered. 14:06:30 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 to clarify, you want to move all items from https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements to this spreadsheet? 14:06:37 blogan: HA will (and must) be provided by the driver 14:06:49 enikanorov: good, thank you 14:06:58 samuelbercovici: i assume just stats? 14:07:04 HA is essential feature, pushing it on orchestration level means that we are making user to configure it 14:07:05 samuelbercovici: I was just going to move the operator data 14:07:19 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 sballe: 'same thing for each driver' is a code reuse issue. drivers actually may want to implement it differently 14:08:01 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 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 samuelbercovici: In terms of feature usage? 14:08:40 So not every driver needs to deliver the same kind of HA. 14:09:11 jorgem: probably my confusion. the excell is only for operator feature statsitics? 14:09:50 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 btw, to make sure we are clear, does operator mean cloud-operator or tenant-operator? I assume cloud-operator 14:10:00 Though, I think the requirements page does this already, too. 14:10:02 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 samuelbercovici: cloud op 14:10:09 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 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 sballe: yes. 14:10:28 There is certainly overlap between the two 14:10:33 what about operators that aren't at liberty to share usage data? 14:10:48 sballe: i think that makes the most sense right now 14:11:11 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 aveiga: We'll have to make decisions without those operators' data, then. :/ 14:11:15 sballe: doe you mean HA proxy is highly available or the load balanced application is highly available? 14:11:18 aveiga: This is why we are using relative data not finite numbers 14:11:22 Since we're essentially a private cloud, "users" are typically "operators" 14:12:39 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 Do we already have a preferred 'common place' for common code? 14:13:03 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 samuelbercovici, I would like the LB service to be resilient 14:13:30 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 sballe: ok thanks 14:13:41 the pool is used to make the LBs resilient 14:14:05 samuelbercovici, it is really a pool of standby LBs 14:14:05 aveiga: Also, new features will most likely not have data so those will be more open to debate. 14:14:14 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 enikanorov_, Agreed 14:14:51 jorgem: thanks for the clarification. I'm trying to get clearance to share, but I can't as of yet 14:15:10 aveiga: No worries, so did I :) 14:15:12 ok, if we're done with discussing usage data/requirements, i'd like to move to the other topic 14:15:20 enikanorov_: Assuming this is HA proxy only, than the API is something available from "HA proxy" management system 14:16:03 samuelbercovici: initially we have a proposal that any driver that needs something specific for operator, could expose API 14:16:31 we had many proposals at icehouse summit, you know :) 14:16:42 doesn't that require an extension like behavior for neutron lbaas? 14:16:59 blogan: it does, and even a little bit more flexible than that 14:16:59 i mean an extension to the neutron lbaas extension 14:17:11 it's not extension on extension, btw 14:17:11 recursive extensions! 14:17:13 enikanorov_: if this is driver specific, it can be available directly from the driver. we can discuss this in ML. 14:17:42 well, we don't have the ability to do 'available directly from the driver' 14:17:52 in fact, we already have such admin API 14:17:59 which is agent scheduling for haproxy 14:18:06 it's embedded into the plugin itself 14:18:08 which is not good 14:18:23 enikanorov_: I agree on that 14:18:37 enikanorov_, so can we move it up sp it is a framework across all plug-ins? 14:18:41 that API could be exposed by haproxy driver, and not be the plugin 14:19:16 sballe: yes, the initial proposal was like that. Btw, lbaas is not the only plugin that needs that 14:19:27 enikanorov_, agreed, 14:19:44 enikanorov_, do you have a blueprint or so I can look at? 14:19:55 sballe: the operator API, UI and capabilities that each vendor provides are difficult to harmonize 14:20:07 sballe: yes, we do. i'll find it shortly 14:21:25 enikanorov_, thx 14:21:42 ok, the next topic i'd like to discuss is API 14:22:02 we heard some claims that existing API is confusing/not user friendly 14:22:15 so i'd like to make some introduction on this topic first 14:22:31 correct and mark mcclain agreed with that 14:22:44 * sballe I agree too ;-) 14:22:44 initially the API was made simplistic to account for the most basic features that every LB solution provides 14:23:01 so there was some simplifications all around 14:23:24 one of the biggest simplification was that we made 'Pool' object - the root object 14:23:35 it was also required to be made cli friendly 14:23:39 e.g. the object with which lb workflow starts 14:23:46 this resulted many 1st level objects 14:23:56 'cli-friedliness' is a must basically 14:24:15 what does 'cli-friendliness' actually mean? 14:24:35 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 ptoohill: it means that user should be able to operate the configuration on per-object basis 14:24:46 ah, thank you 14:25:00 +1 jorgem 14:25:07 jorgem: well, i agree, the problem is that API is made by mortals (e.g. us) :D 14:25:09 it also means, that cli commands should be reasonably short 14:25:17 can we ask a different question? and go top down. What does user friendly mean? 14:25:29 sballe: that's a great question 14:25:39 and that's why i'd like to hear from you 14:25:42 and then figure out if it is even compatible with the model we have now? 14:25:47 sballe: I'll give it a shot... 14:26:09 jorgem, ok 14:26:27 jorgem: please 14:27:04 so, in that case, a single populated object (one call, not many) is not cli-friendly? 14:27:21 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 +1 14:27:34 ptoohill: single call could be an extra, but not the whole API 14:27:59 +1 14:28:01 well of course, but to have all the features contained in the single object sounds friendly to me 14:28:06 jorgem: That's kind of it in a nutshell. ML might be better for this though 14:28:06 then being able to modify those individually 14:28:10 single call has one huuuuge issue 14:28:19 ptoohill: maybe not "all" but "many" 14:28:22 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 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 We spent a lot of time on the Atlas API with this in mind. 14:28:48 Would that also mean a bunch of predefined default settings that suit the purpose of the lb? 14:28:55 sbalukoff: +1, that's what I've been trying to get across -- sane defaults 14:29:03 ok, let me answer these 14:29:05 +1 sbalukoff 14:29:10 BTW our customers love our API in comparison to AWS (they actually state this to us) 14:29:13 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 1. neutron API is quite low-level. it's not an orchestration level 14:29:32 I agree that the Atlas API is a starting point and is the reason that we built LIbra using this API. 14:29:44 2. single call-api is not as simple as it seems 14:29:46 however, it needs work to accomodate new items such as pools 14:29:51 sballukoff: +1 14:29:56 we already do have single call API which is Heat 14:30:15 and it has one important feature 14:30:32 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 id requires you to use it's own definition language 14:30:49 *it 14:30:56 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 and the definition language is required (generally) to work with a graph of objects in a single call 14:31:31 crc32: Heat is separate orchestration project 14:31:54 neutron should provide minimal usability without heat. 14:32:08 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 crc32: the reason to not having single call is technical, not only because 'Heat already has that'. but that as well 14:32:32 orchestrating the configuration of a lb is one thing. Orchestrating the creation/deletion of many lbs is another 14:32:39 rm_work: that's one of the options 14:32:41 jorgem, +1 14:32:43 jorgem: +1 14:32:49 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 I don't think Heat is the place to orchestrate the creation of a single LB 14:33:10 (That would require Heat to manipulate things that aren't in the API, right?) 14:33:19 sbalukoff: +1 14:33:25 sbalukoff: + 1 14:33:38 sbalukoff, +1 14:34:19 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 rm_work: so LBaaS API is not fo orchestraction, but for fine grained conrtol over load balancing function 14:34:25 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 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 rm_work: Ok, yes, I can get behind that. :) 14:34:55 enikanorov_: yeah, but I don't think "create one full LB" falls into "orchestration" 14:35:01 tvardeman: one call doesn't allow you to create rich configuration unless you introduce template language like in heat 14:35:25 rm_work: +1 14:35:25 shouldn't "one call" be enough to instantiate a ddefault LB though? 14:35:25 jorgem, I agree, 14:35:30 enikanorov_: it does if you have sane defaults, aka what sbalukoff was saying earlier 14:35:38 rm_work: I think the term LB is oveloaded 14:35:41 rm_work: not really 14:35:44 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 it's not about defaults 14:35:49 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 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 it's about ability to reference different objects within the configuration 14:36:03 samuelbercovici: Yep, I think we're confusing terms again here. 14:36:17 the thing is that we don't have a single example of such APIs yet 14:36:29 marios: yeah, I can see what you mean there… in that case it's part of a greater whole 14:36:33 none of the lbaas APIs available provides features set we desire 14:36:36 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 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 enikanorov_: That's one of the joys of an asynchronous API 14:37:00 jorgem: can you give a link to API reference? 14:37:06 sure one sec 14:37:14 and it's not about asyncness 14:37:35 #link http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Create_Load_Balancer-d1e1635.html 14:37:51 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 jorgem: yesh, i've seen this page 14:38:12 sorry, this API doesn't fit our requirements 14:38:22 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 because it doesn't support multiple pools 14:38:24 I mean, what "aaS" product doesn't have as a high level object... 14:38:29 (needed for L7) 14:38:49 enikanorov: that can easily be accomplished with that api though 14:38:52 enikanorov_: Right I was just stating that one call can take in a rich config, not necesarily to use this API 14:38:54 and here is the libra API for another example: http://api-docs.test.devex.uswest.hpcloud.net/api/lbaas/ 14:38:59 enikanorov_: I think that could be solved… it only doesn't support that because it was never a req 14:39:01 enikanorov: i mean with modification 14:39:08 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 enikanorov_, we can tweek the APIs to support the more advnaced features 14:39:31 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 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 sballe: we can. it would be Heat API 14:40:00 enikanorov_: correct and I think this can be accomplished 14:40:06 crc32, +1 same for us. the high level API really works well 14:40:24 'here, here' 14:40:25 jorgem: this can be accomplished, but it's strongly an 'extra' feature 14:40:28 enikamprov_: Punting this off to heat is going to complicate something that belongs in the core api. 14:40:31 perhaps ML discussion so we can get in our points? 14:40:38 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 +1 14:40:58 I like the idea of being able to tweak 14:41:11 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 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 +1 rm_work 14:41:35 sbalukoff: Yes we do 14:41:35 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 enikanorov_: do you mean in terms of passing in the required configuration + options (ala heat templates) 14:41:51 sbalukoff: Autoscaling is one for example 14:41:57 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 to clarify, do any of the Rackspace, HP cloud, other , users use cli calls? 14:42:01 blogan_, +1 I totally agree 14:42:01 jorgem: Ok, so you don't force your users to use orchestration for high-level calls, then? 14:42:11 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 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 sbalukoff: We do not 14:42:27 marios: yes, it must be a template. 14:42:44 Got it. 14:42:49 Do he Rackspace, HP cloud, other , users use cli calls? 14:42:53 samuelbercovici: Rackspace has a CLB CLI 14:42:57 Again, many ways to skin the cat, I guess. 14:42:58 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 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 enikanorov_: to be clear, the 'single call api' - is this 'in addition to' or 'instead of' the current API? 14:43:20 rm_work: but is it wildly used? 14:43:23 marios: an addition, only 14:43:29 enikanorov_: ack, tx 14:43:31 samuelbercovici, we have a cli for Libra 14:43:37 samuelbercovici: 90%+ of our LBs are created through webGUI I think :/ 14:43:39 marios: that comes from cli requirement and that follows neutron ideology 14:44:03 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 rm_work: if it's web gui - than user experience goes from gui, not lbaas API 14:44:18 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 samuelbercovici we have cli calls and some users have orchestration with ansible, chef, etc. 14:44:33 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 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 rm_work: horizon already does this methinks 14:45:09 ah, yes, horizon 14:45:09 rm_work: yes. anyway those who pass jsons, make it from scripts, not manually 14:45:10 crc32 +1 14:45:12 rm_work: Correct but we do have the power API users as well 14:45:22 german_: cli that has many many parameters and can encompass multiple lines is ususaly an issue with human users 14:45:25 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 jorgem: yeah, but the power API users could probably handle a "no single-call creation" system 14:45:40 this is why I am asking whether users are using the cli in your environments 14:45:41 samuelbercovici, that why we need good defaults 14:45:42 marios: not really... 14:45:45 crc32: so you'd still have the same lb object. just the creation is different? 14:45:47 or would like it just as much, since they're the 5% i was talking about 14:45:49 yesm we also have horizon we just offer everyhting 14:45:50 enikanorov_: ah, ok... 14:45:51 Ultimately, a GUI is going to be using API on its back-end. :/ 14:45:54 marios: it can't be a wrapper, i'd say 14:46:14 samuelbercovici: I think that was a very good question 14:46:29 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 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 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 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 crc32: well the latter i think 14:47:03 crc32: but i am new here :) so ... 14:47:06 blogan_: just to clarify, i'm not against 'single call' API, but i'm agains making it a primary one 14:47:15 rm_work, it;s the same for us 14:47:27 jorgem: +1 14:47:41 blogan: a way to configure a large object tree, would be to "batch" multiple calls together and then execute whne done 14:47:43 jorgem: i don't think I am anymore <_< 14:48:10 you mean the api batches them together? 14:48:17 this leaves the notion of multiple short api calls but allows to populate an object graph before actually amking a call 14:48:21 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 I would assume the orchestration layer does 14:48:23 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 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 It really shouldn't be hard to implement unless I am missing something 14:49:04 enikanorov_: I agree. sub resources in a RESTful API are nice 14:49:07 crc32: i'm not against adding single call to lbaas API as an extra 14:49:18 blogan_: I will send some examples on ML 14:49:20 crc32: Heat has it's drawbacks 14:49:31 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 samuelbercovici: ok thanks 14:49:40 crc32: but the thing is that single-call API would not be a simple json call 14:49:45 yeah, we need to keep it possible so users can use other orchestration software 14:49:50 crc32: it will require template language 14:50:28 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 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 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 enikanorov_, as long as we only create one lb I am not sure we need some template language 14:50:47 sbalukoff: +1 14:51:02 german_: that's not about 1 lb 14:51:03 enikanorov_: I mean add it as a requirement that the api should support both. 14:51:21 german_: 1 lb may have several vips and several pools. thea are cross-referenced in configuration 14:51:27 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 This implies a different work-flow for using advanced features, and I'm OK with this. :) 14:51:30 german_: that's what template language is for 14:51:34 Possible action item for new API proposols??? 14:51:46 samuelbercovici: good suggestion 14:52:01 samuelbercovici, +1 14:52:07 in fact we've already done that in recen obj model discussion :) 14:52:23 samuelbercovici: + 14:52:24 It sounds that every single call should consider sane defaults as a basis, right? 14:52:25 samuelbercovici: jorgem: +1 i think we need to have specific 'thing' to discuss/approve/shoot down. 14:52:44 aburaschi: what do you mean? 14:52:50 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 web gui is out of scope, definitely 14:53:19 marios, +1 14:53:23 enikanorov: how are decisions made? is it all by core reviewers? is it majority rules? committers only? 14:53:52 Oh! Sorry, I misunderstood what samuelbercovici suggested. 14:53:55 blogan_: that's a hard question... 14:54:06 oh wow. Are heat templates yaml files or is it an actual language with a grammer and such forth. 14:54:08 ? 14:54:18 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 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 crc32: it is. we need particular feature from that language 14:55:02 crc32: i've only ever seen yaml templates. but there is definitely a grammar that is parsed by the heat engine 14:55:05 aburaschi: still not sure i get your question 14:55:38 even if web UI are out of scope, they may represent how users visualize the configuration 14:55:49 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 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 and could be used as another sanity check for the api as obviously the web use consumes the api 14:56:58 samuelbercovici: That's a good point. I'm glad I misunderstood your suggestion above, in retrospect. :D 14:57:02 thats right up their with writing a DSL in XML and yes we've had the torture of doing that. :( 14:57:10 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 crc32: yaml files, where individual tags within have specific meaning/action 14:57:20 crc32: not a very big deal, but a thing to consider 14:57:45 crc32: (fyi example templates that tripleo uses @ https://github.com/openstack/tripleo-heat-templates) 14:58:15 enikanorov_: Before meeting ends do we have proper action items lined out? 14:58:18 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 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 jorgem: i'll send them after the meeting shortly 14:59:04 enikanorov_: thanks 14:59:05 samuelbercovici: may be i'd separate web ui discussion... 14:59:17 +1 enikanorov_ 14:59:23 enikanorov_: ok. will do 14:59:41 yeah that is a weird case, because it is related, but really "not our problem" right now 15:00:03 rm_work: GUI creators will be big API users though 15:00:03 ok, thanks everyone for joining, lets wrap up and continue in ML 15:00:13 They will. 15:00:17 thank you 15:00:17 #endmeeting