18:00:23 <SlickNik> #startmeeting trove-bp-review
18:00:24 <openstack> Meeting started Mon Jul 14 18:00:23 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:27 <openstack> The meeting name has been set to 'trove_bp_review'
18:00:35 <grapex> o/
18:00:39 <amcrn> o/
18:00:41 <dougshelley66> o/
18:00:43 <boden> o/
18:00:48 <glucas> \o
18:00:59 <amrith> o|
18:01:04 <SlickNik> Agenda for the meeting at:
18:01:06 <esmute> \o/
18:01:06 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting
18:01:06 <tvoran> o/
18:02:21 <esp> o/
18:02:33 <vipul> o/
18:02:42 <schang> o/
18:03:00 <SlickNik> #topic New API call to get the default configuration values for a specific datastore version flavor without an instance
18:03:19 <SlickNik> cp16net: around?
18:04:24 <cp16net> SlickNik: yeah
18:04:26 <cp16net> i'm here
18:04:28 <peterstac> o/
18:04:40 * cp16net was off in lala land for a min :-P
18:05:02 <SlickNik> So I had a couple of questions.
18:05:04 <grapex> Is that the place Loney Tunes characters go when they say "ooh la la!"
18:05:05 <grapex> ?
18:05:39 <cp16net> yeah so this was asked from some ui devs that wanted to present the defaults of a configuration that isnt attached to an instance
18:05:59 <SlickNik> This is just a call to get the default config params per flavor, right — no tackling setting of defaults?
18:06:37 <cp16net> the idea i have is to read the template based on flavor/datastore version and present it to the user
18:07:04 <cp16net> SlickNik: so yeah just a simple GET call for these vaues
18:07:07 <cp16net> values*
18:08:08 <cp16net> any questions about the use case?
18:08:13 <vipul> So i have 2 things about the proposal
18:08:27 <vipul> 1. i don't agree with the URL -- why do you have flavor_id as part of the URL
18:08:52 <vipul> 2. we call the defaults that ocme back on an instance 'parameters'.. should this be named similarly
18:09:03 <vipul> i.e GET /instances/{instance_id}/parameters
18:09:15 <cp16net> 1. so based on a template it could change per flavor size (memory settings)
18:09:39 <cp16net> 2. i would agree with you on that.
18:09:50 <grapex> cp16net vipul: regarding #1, would it be acceptable if it was in their but the path put flavor right after the dv_id?
18:09:59 <vipul> so is there another way to specify flavor outside of the path?
18:10:02 <grapex> So that would be /datastore/version/{dv_id}/{flavor_id}/parameters
18:10:37 <vipul> grapex: that would be better.. configuration/{flavor_id} makes it seem like flavor_id should be the id of configuration
18:11:05 <grapex> vipul: In many ways it is. Operators can already specify a configuration template using a flavor
18:11:09 <grapex> What if in addition to that
18:11:10 <cp16net> grapex: brings up a point that i noticed for some calls like this one
18:11:37 <cp16net> we are not really following a RESTy call here
18:11:45 <cp16net> its more like a shim to get the data we need
18:12:21 <vipul> yea.. ideally it would be a filter via query string
18:12:43 <cp16net> filters are just a pain in the arse with how they work today
18:12:52 <grapex> vipul: I think there's some issues here though because an operator can create templates for each flavor. To me that means they deserve a complete REST path
18:13:01 <amcrn> cp16net: i just added a filter for clustering; there's a bit of a trick to it, i can give you some pointers
18:13:01 <vipul> somethign like /datastore/version/{dv_id}/parameters may return something generic.. but /datastore/version/{dv_id}/parameters?flavor_id=xxx woudl return something specific to that flavor
18:13:24 <cp16net> amcrn: ok
18:13:46 <grapex> vipul cp16net: So I'm curious why considering the pairing of a datastore version and a flavor in a rest url would be a bad thing.
18:14:32 <vipul> do configuration groups belong to datastore_version + flavor, or do they belong to datastore versions
18:14:33 <cp16net> i dont think its a "bad thing" but just the relationship between the noun and ids dont match
18:14:46 <grapex> vipul: They do both
18:14:56 <cp16net> ds_version and instance
18:15:18 <cp16net> rather and/or
18:15:26 <grapex> cp16net: But you added code so an operator can uniquely identify a config via a ds_version and a flavor
18:15:37 <cp16net> grapex: correct
18:15:46 <vipul> the fact that you can get defaults per flavor doesn't necessarily mean that they are full on resources that a flavor owns
18:16:15 <vipul> like cp16net said, the full on resource actually belongs to an instance + datastore
18:16:38 <cp16net> #info https://github.com/openstack/trove/blob/master/trove/templates/mysql/config.template#L16
18:16:45 <cp16net> or i guess that shoul dhave been a link
18:16:51 <cp16net> #link https://github.com/openstack/trove/blob/master/trove/templates/mysql/config.template#L16
18:16:58 <grapex> vipul: but we're not talking about instance + ds_version  but the default templates which are grouped via ds_version and, optionally, flavors
18:17:19 <cp16net> so this default template has a different key_buffer_size per flavor
18:17:32 <cp16net> even tho the template is the "base" one
18:17:48 <cp16net> so you still need a flavor
18:18:12 <grapex> Ok- so let's go with the query parameter. If you don't specify it, what would you see for "key_buffer_size"?
18:18:23 <esmute> what about /datastore/version/{dv_id}/configuration/flavor/{flavor_id}? It is a bit verbose.. but more resty
18:18:27 <grapex> In the call to get defaults from the API, what would that look like if a flavor wasn't specified?
18:18:31 <cp16net> an exception
18:19:02 <cp16net> (i assume)
18:19:07 <cp16net> robertmyers: might know better
18:19:18 <grapex> Look at this: https://github.com/openstack/trove/blob/master/trove/common/template.py#L87
18:19:30 <SlickNik> So apart from figuring out the right URI for this, are folks good with the BP?
18:19:53 <amcrn> cp16net: to go back to the purpose of this change, i'm not sure why this is necessary if the user can change the value after it's been deployed. if they know the available memory (via flavor), they can tweak the buffer_pool_size to their heart's content.
18:20:00 <grapex> according to that logic, the three required parameters are the datastore version info, the flavor, and the server_id (which is just a unique id). So this command would need the first two as input and not the third
18:20:29 <cp16net> amcrn: the idea is to show a user from a ui what the "default" is
18:20:36 <cp16net> then they can tweak it all they want
18:20:48 <amcrn> so, other than that being a nicety, can you explain why showing the default will change user behavior?
18:20:56 <cp16net> think about it as fields you can change but the default is greyed out or something
18:21:06 <amcrn> because it feels it will drive up capacity usage because they think they can't change the value post-deployment.
18:21:22 <SlickNik> grapex / cp16net: Can these defaults just as easily be part of the documentation?
18:21:28 <cp16net> amcrn: its really a niceity that was requested
18:21:39 <grapex> cp16net: Is this so if someone changes their instance to some strange config values they can later view what the normal ones were
18:21:49 <cp16net> SlickNik: they could not be generated automatically
18:21:56 <cp16net> if they are tweaked in a template file
18:22:29 <grapex> SlickNik: Sure, but these are values that might be tweaked more often that other deployment settings
18:22:30 <cp16net> +1 to grapex comment as well
18:22:43 <cp16net> the event of OH CRAP i screwed it up
18:23:00 <cp16net> revert and hopfully someone can fix it on their own
18:23:24 <amcrn> as a user, if see that configuration-parameter 'x' is defaulted to 'y' with a flavor, i'm going to naturally keep bumping the flavor until it meets my needs, unless the ui is very clear that i can change this configuration-parameters post-deployment. this situation might be good for deployers making money on larger flavors, but for internal deployments, it might be encouraging behavior that's unnecessary.
18:23:51 <dougshelley66> doesn't it also seem useful to know what values will be set if you don't have a config group or detach a config group?
18:23:56 <amcrn> so in short, i'd have to see mocks to be sure whether this is a good idea from a ui-perspective.
18:24:02 <grapex> amcrn: ah
18:24:19 <amcrn> and my english is terrible this morning, apologies.
18:24:25 <grapex> I don't think the intention is people look up what each flavor provides so much as, when they change config values on an instance in a UI, they can see what the default settings were
18:24:52 <amcrn> grapex: oh, so this is more for a configuration-group view vs. Launch Instance modal?
18:25:05 <grapex> amcrn: I think so. cp16net is that correct?
18:25:13 <cp16net> yes this is for config-group
18:25:30 <cp16net> because you can create a config group without an instance
18:25:43 <amcrn> consider my concern squashed then, thanks for the clarification.
18:26:04 <cp16net> ok cool thanks grapex for helping clarify
18:26:04 <SlickNik> cp16net / grapex: But you can get the defaults from the instance if one is already created today, right?
18:26:11 <cp16net> yes
18:26:32 <SlickNik> I thought that this was for the scenario where an instance has *not* been created yet.
18:26:46 <cp16net> yes
18:27:11 <grapex> Hmm... that seems like overkill to me, as there will be two paths to get the same data. cp16net there's only one path shown in the wiki
18:27:15 <cp16net> or maybe you dont want to create instance with 16GB just to find out what the memory settings are for mysql
18:27:29 <cp16net> thats another use case
18:27:49 <cp16net> grapex: the other path already exists
18:27:50 <amcrn> given that deployers can change these templates, i'd agree that having an api to return the default parameter values makes sense.
18:28:06 <cp16net> #link https://github.com/openstack/trove/blob/master/trove/common/api.py#L92
18:28:06 <grapex> cp16net: Oh, sorry. :(
18:28:09 <cp16net> grapex: ^^
18:28:16 <nehav1> yes thats correct this scenario is when no instance is tied to the configuration groups. This api call will allow users to see the defaults and the parameters that can be tweaked
18:28:36 <vipul> yea, agree the use case seems valid..
18:28:54 <cp16net> ok so everyone agrees with the use cases
18:28:58 <vipul> did we agree on URI ? sorry was away for a bit
18:29:03 <cp16net> so the only issue we have is the URI
18:29:25 <amcrn> => /{tenant_id}/datastores/versions/{version}/parameters?flavor_id=<x> and /{tenant_id}/datastores/versions/{version}/parameters/{name}?flavor_id=<x> looks good to me.
18:29:44 <vipul> +1 to query string approach
18:30:07 <glucas> sorry.. on the use case, do you really want to pick a flavor and see the values or do you want to see the formula?
18:30:30 <cp16net> so 1 question... what happens when no query string is suppiled
18:30:34 <grapex> So... I'm ok with the query string approach as I don't worship at the alter of REST. But I feel like I never got a good answer on what the result would look like if a flavor wasn't used.
18:30:36 <vipul> i thik you can return the formula if there is no query string
18:30:37 <SlickNik> glucas: What if there isn't a formula and it's hard coded per flavor?
18:30:51 <grapex> vipul: As in return the non-interpolated jinja template values?
18:31:04 <vipul> :) that's an option
18:31:19 <grapex> Return "[!please use query string]"
18:31:20 <glucas> SlickNik: Hm, OK. Didn't see that case in the example I was looking at.
18:31:25 <amcrn> grapex: not sure i understand the question, because both of those routes exist today
18:31:31 <SlickNik> Okay, I think we've spent some time on this already.
18:31:37 <SlickNik> And need to move on.
18:31:38 <cp16net> that could be gross
18:31:49 <SlickNik> cp16net: I think all of us agree on the use-case.
18:32:02 <SlickNik> And the requirements for the BP.
18:32:02 <grapex> SlickNik: Ok. I'm satisfied either way so long as there's tests proving usage isn't crazy.
18:32:21 <cp16net> because the template file *can* be made many different ways
18:32:35 <cp16net> not just the formulas of the fields
18:32:55 <SlickNik> So I think we're good approving it. I trust we can come up with the right URI as part of the follow-up, and code review.
18:32:58 <SlickNik> Folks okay with that?
18:33:04 <glucas> +1
18:33:04 <grapex> SlickNik: +1
18:33:08 <vipul> yep +1
18:33:11 <dougshelley66> +1
18:33:11 <cp16net> +1
18:33:14 <amcrn> +1
18:33:15 <peterstac> +1
18:33:19 <boden> +1
18:33:20 <SlickNik> Okay, let's move on.
18:33:24 <cp16net> thanks
18:33:29 <SlickNik> #topic configurable db plugins
18:34:02 <SlickNik> boden: I agree with your assessment on this one
18:34:14 <grapex> So we're talking about dropping it?
18:34:17 <boden> yes
18:34:23 <SlickNik> #info (boden) Based on our previous discussion I propose we drop this BP as (a) no other projects expose this level of integration and (b) this couples consumers into an internal impl detail which is not guaranteed to be supported long term.
18:35:03 <SlickNik> Anyone have anything to add for this one?
18:35:04 <vipul> so is thre anything to review on this?
18:35:11 <boden> vipul -- no code
18:35:12 <dougshelley66> does that mean we vote -1 :)
18:35:21 <grapex> dougshelley66: lol
18:35:21 <SlickNik> Nope, I think boden was just closing the loop.
18:35:25 <SlickNik> Thanks boden.
18:35:36 <SlickNik> #topic multiple API extension paths
18:35:41 <cp16net> ok thanks for the follow up
18:35:48 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/extensions-update
18:35:57 <boden> prelude -- this one may need a flished out BP in wiki, just wanting to get some initial thoughts
18:36:23 <boden> so right now the conf supports api_extensions_path to point to the API route extension classes
18:36:39 <boden> but it only supports a single path -- where the trove extensions already exist...
18:37:20 <boden> if as a consumer I want to add some custom extensions I have to copy them into the path where the trove extensions live... what I'm proposing is a comma list conf property to support multipel extension paths
18:37:59 <boden> again -- I will write this up more formally if folks think this is the proper approach
18:38:03 <grapex> I don't think there will be any dissension on this one. Btw, are we still importing files based on the physical file path or did that get fixed so its using true Python imports now? I can't remember.
18:38:28 <SlickNik> Seems like a reasonable approach to me. Would like to see it fleshed out.
18:38:32 <glucas> grapex: still using a file path I believe
18:38:44 <vipul> how about if we're doing this.. we migrate to stevedore
18:38:45 <SlickNik> grapex: I believe we're still using file paths, not python modules.
18:39:00 <grapex> This Steve Dore is a popular guy
18:39:07 <boden> SlickNik -- agreed... however do you agree this would be separate from the 'extensions update' BP?
18:39:10 <cp16net> yeah i was waiting for that...
18:39:11 <cp16net> :_P
18:39:23 <vipul> haha yea.. he gets around
18:39:27 <amcrn> i vote we use steveholt
18:39:33 <grapex> amcrn: +1000
18:39:39 <grapex> Let's propose it for Oslo
18:39:55 <SlickNik> lol
18:40:02 <vipul> #link http://stevedore.readthedocs.org/en/latest/
18:40:07 <cp16net> i think we should have that as a separate task
18:40:11 <grapex> SlickNik vipul: Saying this should be with Steve Dore is close to saying the extension thing *can't* be fixed unless it changes entirely to stevedore
18:40:16 <vipul> it's the way most of the porjects manage extension
18:40:32 <SlickNik> boden: I think it would be different from that.
18:40:52 <boden> SlickNik -- I will write it up as a separate BP + wiki then
18:40:57 <SlickNik> boden: but a lot of our extensions code is taken from old nova code, that needs a refresh.
18:40:57 <cp16net> boden: nice
18:41:01 <vipul> grapex: yea maybe it's too much to require that.. it is a suggestion.. if it's simple to migrate to.. we should do it
18:41:01 <grapex> I agree we should use it. Although the next thing I think is "great, this will screw up our deployments the moment it lands..." How easy would it be to add stevedore and keep backwards compatibility to avoid that?
18:41:07 <vipul> i'm fine with doing it as a separete thing too
18:41:25 <amcrn> i'd agree to keep the two separate
18:41:32 <boden> ok
18:41:33 <cp16net> so i think its a quick win to change the option to a list_opt to support multiple paths for extentions
18:41:38 <vipul> the more we specialize our extensions, the harder it becomes to migrate off
18:41:47 <cp16net> ... althoughi  really hate the list_opt
18:41:53 <grapex> I want to move to stevedore too btw, I know robertmyers would be happy. :)
18:42:47 <SlickNik> boden: Can you look into doing this vs. updating the extensions to use stevedore to see how much more work it is, as you flesh out the bp?
18:42:59 <boden> SlickNik -- can / wikk do
18:43:04 <boden> *will*
18:43:25 <SlickNik> boden: Then based on that we can decide if we want to tackle one vs. both, and the order of things.
18:43:28 <SlickNik> boden: Thanks!
18:44:47 <SlickNik> #topic Open Discussion
18:44:55 <SlickNik> did folks have anything BP related?
18:45:59 <SlickNik> Looks like not.
18:46:07 <SlickNik> #endmeeting