18:01:16 <hub_cap> #startmeeting #trove
18:01:17 <yogesh> 5hello
18:01:17 <openstack> Meeting started Wed Dec  4 18:01:16 2013 UTC and is due to finish in 60 minutes.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:19 <yogesh> hello
18:01:20 <imsplitbit> /o/
18:01:21 <ashestakov_> o/
18:01:21 <openstack> The meeting name has been set to '_trove'
18:01:23 <grapex> o/
18:01:23 <imsplitbit> \o\
18:01:24 <robertmyers> o/
18:01:27 <imsplitbit> \o/
18:01:28 <pdmars> o/
18:01:28 <amcrn> \o
18:01:29 <kevinconway> o/
18:01:33 <datsun_F40PH> o7
18:01:33 <denis_makogon> o/
18:01:37 <cp16net> o/
18:01:38 <isviridov> o/
18:01:40 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:01:40 <SlickNik> here
18:02:10 <cweid> o/
18:02:27 <denis_makogon> whazzap 2 all
18:02:37 <hub_cap> #topic separate guest agent
18:02:41 <hub_cap> denis_makogon: go
18:02:41 <imsplitbit> ))))))))
18:03:05 <denis_makogon> #link https://github.com/denismakogon/trove-guestagent
18:03:09 <juice> o/
18:03:32 <denis_makogon> last few days i was working on extracting guestcode into it's own repo
18:03:49 <denis_makogon> manually i ran all testcases
18:03:49 <hub_cap> awesome denis_makogon
18:03:51 <SlickNik> denis_makogon: nice!
18:03:59 <robertmyers> looks good
18:04:04 <denis_makogon> i mean create/backup/restore/resize
18:04:26 <hub_cap> denis_makogon: when we really go about creating the guest, we can use a git subtree to keep the history
18:04:29 <denis_makogon> for now i've got problems with few tests which are using DB connection
18:04:50 <vipul> o/
18:05:14 <kevinconway> hub_cap: +1
18:05:27 <imsplitbit> +1 subtree
18:05:31 <cp16net> +1.5
18:05:31 <imsplitbit> )))))
18:05:37 <datsun_F40PH> +1 yeah let's preserve that history
18:05:38 <denis_makogon> so, question is: do we plan to integrate guestcode ?
18:05:46 <grapex> hub_cap: Yeah, that history goes back a year and half- let's do the subtree thing.
18:05:50 <kevinconway> denis_makogon: yes, it should be merged with trove repo
18:05:53 <SlickNik> another thing denis_makogon. Can you split off the git subtree, rather than have one big initial commit? This preserves git history...
18:06:25 <kevinconway> denis_makogon: but first separate it, then merge it back in
18:06:30 <denis_makogon> SlickNik, i would try
18:06:32 <hub_cap> ok cool. this brings up an interesting question, if i want to make changes to my guest, and i edit my local code, how does that code get into the instances i provision?
18:06:36 <hub_cap> im worried less about tests, cuz the openstack pypi stuff is set up to handle this, but for day to day devrlopment
18:07:12 <denis_makogon> maybe git clone/pull ?
18:07:24 <hub_cap> denis_makogon: its necessary
18:07:36 <hub_cap> plz figure out how to do it and use that as the repo
18:07:41 <datsun_F40PH> i guess you'd have to set up your local repo as the authority
18:07:50 <grapex> hub_cap: Do you mean when you're developing? Doesn't the rsync trip pull that in? Just point it somewhere else.
18:08:24 <grapex> Seems like this is yet another thing that will live in /opt/stack
18:08:43 <robertmyers> add it to devstack?
18:08:55 <hub_cap> grapex: fair enough, but the "delivery" part is what hes talking about
18:09:01 <grapex> and rsync will pull it from there; devstack will clone it if it doesn't exist, and people will make it a shared folder if they're using a VM
18:09:05 <kevinconway> datsun_F40PH: when will vagrant be updated for this?
18:09:19 <denis_makogon> grapex, yes, i was playing with redstack and guest
18:09:24 <datsun_F40PH> kevinconway: when someone submits a pull request and i feel like merging it
18:10:22 <denis_makogon> #action denis_makogon: use git subtree for guestcode
18:11:05 <kevinconway> denis_makogon: it looks like you made changes to agent after moving it out?
18:11:20 <hub_cap> ok so what do we have to make decisions on here?
18:11:24 <denis_makogon> kevinconway, clean-up
18:11:35 <kevinconway> was it needed to move the agent?
18:11:50 <datsun_F40PH> +1 that concern
18:12:01 <hub_cap> do not do any cleanup unless its necessary
18:12:07 <kevinconway> it's great to clean it, just make sure to keep the original branch unchanged
18:12:07 <denis_makogon> kevinconway, i was trying to keep agent code up-to-date wit trove repo
18:12:12 <hub_cap> we can clean up in a second commit
18:12:30 <denis_makogon> ok, i will revert all my own changes
18:12:53 <kevinconway> denis_makogon: when you do the subtree merge and restore history you can branch off master and re-apply your changes
18:12:56 <kevinconway> no big deal
18:12:59 <denis_makogon> hub_cap, question it that how to keep guest code up-to-date
18:13:00 <datsun_F40PH> denis_makogon: don't take matches to it, lean on git to help you maintain your work
18:13:27 <denis_makogon> ok
18:13:29 <denis_makogon> thanks
18:13:46 <hub_cap> moving on?
18:13:54 <denis_makogon> yes
18:14:23 <hub_cap> #topic configuration parameter deathmatch
18:14:28 <hub_cap> cp16net: denis_makogon go go go
18:14:29 <denis_makogon> #link https://gist.github.com/denismakogon/7789831
18:14:40 <cp16net> lol
18:15:02 <denis_makogon> i described all problems with current implementation of parameters configuration
18:15:11 * imsplitbit tosses some rusty hatchets into the ring
18:15:15 <datsun_F40PH> i'm on team "send the whole file and keep the GA dumb"
18:15:20 <denis_makogon> #link https://review.openstack.org/#/c/53168/
18:15:24 <grapex> I like keeping the guest agent dumb too.
18:15:31 <hub_cap> heh denis_makogon next time put this on the meeting agenda so we can view it before hand
18:15:41 <denis_makogon> sorry
18:15:47 <denis_makogon> forgot
18:16:18 <denis_makogon> guest dumbness defined by database
18:16:57 <SlickNik> +1 to keeping the guest-agent dumb.
18:17:14 <SlickNik> Still reading the gist. Might need clarification on a couple of points.
18:17:17 <imsplitbit> denis_makogon: can you explain that?
18:17:28 <amcrn> can someone clarify what "keep the guest agent dumb" means in terms of action-items as compared to what's in the current review?
18:17:30 <cp16net> denis_makogon:   - do not call configuration groups - overrides, it too mysql specific;
18:17:34 <amcrn> i'm not fully groking this gist
18:17:41 <grapex> amcrn: It means having the server create the full and send it over
18:17:43 <hub_cap> ya ir confused a bit
18:17:44 <cp16net> what do you mean?
18:17:51 <datsun_F40PH> amcrn: the alternate would mean the GA gets to figure out templating and filling in the blanks and locations and such
18:17:56 <grapex> amcrn: Versus sending over only what to change in db specific terms, and having the guest apply changes to the file
18:18:26 <denis_makogon> grapex, Amazon RDS doing merging
18:18:53 <denis_makogon> as i said, only mysql could start with more then one conf file
18:18:58 <denis_makogon> out of box
18:19:05 <imsplitbit> not true
18:19:09 <imsplitbit> redis can
18:19:18 <denis_makogon> i've researched
18:19:24 <imsplitbit> but I'd love to hear more about servers that cannot
18:19:28 <denis_makogon> prof ?
18:19:29 <cweid> redis can use more than one conf file.
18:19:40 <imsplitbit> it?
18:19:50 <amcrn> grapex: if it's moved to the server, will it still consult the ga for the source-of-truth, therefore requiring multiple roundtrips?
18:19:53 <grapex> denis_makogon: True they do, however they don't support multiple datastores either.
18:19:56 <denis_makogon> imsplitbit, mongo, cassandra, postgresql
18:20:12 <kevinconway> so the payload that comes from the server includes a whole new config or just a partial?
18:20:29 <amcrn> grapex: i.e. ask the ga what the default values were, then merge the change-set, then push the entire set
18:20:38 <denis_makogon> i vote for only part
18:20:51 <grapex> amcrn: Not sure- last I checked, there's no round trip.
18:20:53 <hub_cap> denis_makogon: postgresql and redis can do a conf.d w/ 1 line in their configs
18:20:56 <grapex> cp16net: Can you confirm?
18:21:12 <amcrn> well now there isn't, but if it's moved from ga to server, what will it be
18:21:16 <datsun_F40PH> i think just providing a "get the current config" call would suffice
18:21:36 <datsun_F40PH> let someone smarter than six lines of awk do the merging work
18:21:58 <robertmyers> datsun_F40PH: +1
18:22:02 <denis_makogon> datsun_F40PH, that's the problem, because there could be special config changes to make DB available for any hosts
18:22:07 <hub_cap> no merge
18:22:12 <hub_cap> push the entire config down
18:22:12 <amcrn> denis_makogon: details?
18:22:17 <datsun_F40PH> denis_makogon: in that case you employ a DBA to make those changes
18:22:18 <SlickNik> robertmyers: did you just volunteer yourself? :)
18:22:22 <hub_cap> there is no need to "merge"
18:22:26 <robertmyers> SlickNik: sure
18:22:30 <vipul> are we talking about database config like a my.cnf or guest agent config trove-guestagent.conf
18:22:32 <grapex> amcrn: The server is assumed to be the source of truth currently.
18:22:42 <robertmyers> vipul: my.cnf
18:22:51 <grapex> vipul: my.cnf
18:22:54 <SlickNik> my.cnf
18:22:56 <vipul> k thanks
18:23:00 <hub_cap> MY.CNF
18:23:03 <vipul> :p
18:23:04 <hub_cap> just in case u didnt get that vipul
18:23:13 <amcrn> other than thinning down the guestagent, what is this buying us?
18:23:28 <datsun_F40PH> the power to tune
18:23:42 <denis_makogon> suppose, i need to set bind address to eth0 inet addr
18:23:57 <grapex> amcrn: A better question is what's it costing us?
18:24:01 <denis_makogon> but server didn't knew, that guest doing such thing
18:24:25 <robertmyers> denis_makogon: why is the guest changing the config?
18:24:33 <grapex> denis_makogon: Would you do that via the API?
18:24:34 <kevinconway> denis_makogon: it would be the same process as when the guest first wrote the config
18:24:36 <amcrn> it must just be me, i'm having a hard time summarizing the positive net benefit of doing this (vs. not doing this)
18:24:37 <denis_makogon> simple example https://review.openstack.org/#/c/51884/19/trove/guestagent/datastore/cassandra/manager.py
18:25:38 <SlickNik> amcrn: you're not alone, I'm trying to think through the exact same thing.
18:25:55 <cp16net> i'm getting a little lost in this convo
18:26:19 <vipul> cp16net: +1
18:26:23 <hub_cap> ok amcrn re-summarize
18:26:24 <denis_makogon> current design works only with databases which could start with more then one conf file
18:26:50 <hub_cap> if there is no net gain/loss, then we dont change anything until we need it <--- general rule
18:26:52 <denis_makogon> so you are saying that trove would not work with DBs which cannot do such thing ?
18:26:58 <SlickNik> amcrn: I think it makes the guest API much simpler.
18:27:20 <ashestakov_> im agree with dmakogon, will better to send array with K:V parameters through rpc, and render config in manager class
18:27:42 <hub_cap> ashestakov_: why is that better?
18:27:54 <grapex> denis_makogon: Would it though? It seems like if the db had only one conf file, you could just overwrite that file every time
18:27:54 <hub_cap> i can send a string or a dict.. what is the difference?
18:28:09 <grapex> Unless the idea is there is some secret stuff on the guest machine you don't want to overwrite
18:28:09 <amcrn> +1 to grapex's comment, that's where i'm lost
18:28:14 <ashestakov_> hub_cap: for DBs which dont support multiple configs, manager can render all settings to one file
18:28:31 <ashestakov_> its more flexible then send renderd configs
18:28:56 <robertmyers> why not just send one file then?
18:29:03 <robertmyers> the whole config
18:29:04 <ashestakov_> or one file..
18:29:06 <denis_makogon> suppose trove creates database, why do i need reconfigure it to make it available for r/w operations ?
18:29:14 <grapex> ashestakov_: I disagree, rendered configs could be generated in nearly any way- there's nothing that's unflexible about it except that it replaces the entirety of what's on the guest machine
18:29:16 <hub_cap> except then the rendering occurs in the guest and that cost more memory wise, and u need the templates in the guest
18:30:02 <amcrn> oh, i think i get the gist of what denis_makogon is saying. example: if you have a datastore that doesn't support multiple confs, say you apply some changes with configuration "a". if the user sends in configuration "b" as an update, it's not straightforward to ascertain what the original/virgin/default conf was.
18:30:27 <ashestakov_> maine point: need to render config depends on manager class, for mysql can has my.cnf and conf.d/my.cnf
18:30:29 <amcrn> unless the datastore has a operation to say "print-defaults" of course
18:30:33 <hub_cap> amcrn: u can regen the "default" from the config template w/ the updates passed in
18:30:35 <datsun_F40PH> so then it's up to each impl's GA to figure out what "all the configs" means
18:30:37 <grapex> amcrn: So when you first do those changes with configuration "a", who or what does that?
18:30:43 <vipul> that's part of documentation isn't it?
18:30:43 <ashestakov_> but for mongo we can have only /etc/mongodb.conf
18:30:57 <datsun_F40PH> maybe it's a list of different file locations and their respective contents
18:31:09 <kevinconway> ashestakov_: why couldn't guest agent just write new config to /etc/mongodb.conf?
18:31:12 <cp16net> we have the default conf from rendering the conf again
18:31:17 <amcrn> hub_cap: today you can't, because only the overrides are stored in the database
18:31:22 <hub_cap> ok i think we need to move forward and push this to after the meeting or the ML
18:31:24 <imsplitbit> I'm wondering if we shouldn't really hash this out more on the ML
18:31:29 <imsplitbit> it's 12:30
18:31:31 <cp16net> thats nothing more than whats happening in the create instance
18:31:37 <imsplitbit> or halfway through the meeting
18:31:43 <ashestakov_> kevinconway: coz, we have template with common settings and user defined settings
18:31:46 <hub_cap> amcrn: but the config.template is stored in the taskmgr too
18:31:58 <amcrn> hub_cap: oh yeah, whoops ;)
18:32:04 <hub_cap> so why dont we just regen each config.template + diff'd parameters and send that file down
18:32:16 <SlickNik> so if all the overrides are in the db, couldn't you just send out a default conf + _all_ overrides to the guest agent.
18:32:20 <hub_cap> single file should be ok
18:32:23 <SlickNik> That way it gets a + b
18:32:27 <hub_cap> i think SlickNik and i said the same thing
18:32:31 <ashestakov_> kevinconway: sure we can render all settings in one file, but this should be done for all datastores
18:32:39 <amcrn> that approach generally makes sense to me
18:32:58 <denis_makogon> hub_cap, why not to send dict with options and let manager decide how to apply it ?
18:33:04 <kevinconway> ashestakov_: this seems like only an issue of how to get the new config to the agent. the agent can do what it wants with it.
18:33:20 <hub_cap> what do they have to decide?
18:33:26 <grapex> denis_makogon: In addition to making the guest smart, sending a dict down means you assume that everything will be in some format that will be easy to modify using a dictionary
18:33:32 <hub_cap> if, always, we send down 1 file, what decision is to be made?
18:33:37 <grapex> So it's a different assumption
18:33:41 <amcrn> +1 hub_cap grapex
18:33:53 <hub_cap> ok but srsly
18:33:55 <grapex> It sounds like we need to keep this more flexible
18:34:00 <hub_cap> moving on. lets punt to after meeting
18:34:03 <SlickNik> let's move on.
18:34:06 <imsplitbit> +1
18:34:07 <hub_cap> good topic :)
18:34:07 <cp16net> ok
18:34:08 <grapex> so we should send down a file- but maybe we should allow the guest agent to apply it differently
18:34:08 <datsun_F40PH> even if you decide that we'll only send one file we can't stop an intrepid tuner from doing that themselves
18:34:09 <imsplitbit> def
18:34:12 <datsun_F40PH> and then what do we do
18:34:12 <kevinconway> hub_cap: can we do ML and not post-meeting?
18:34:28 <denis_makogon> grapex, that it what i say
18:34:28 <imsplitbit> +1 ML
18:34:30 <amcrn> +1
18:34:33 <konetzed> +1 ML
18:34:34 <datsun_F40PH> but i guess once you enable root all bets are off anyway
18:34:36 <hub_cap> ++ML
18:34:39 <imsplitbit> this is a big discussion
18:34:48 <hub_cap> #topic compat client changes
18:34:51 <grapex> datsun_F40PH: Enabling root is like spitting in the face of our precious API!
18:35:01 <datsun_F40PH> grapex: and yet still allowed
18:35:04 <denis_makogon> but i would not prefer to use raw string, vote for dict
18:35:10 <hub_cap> so there was a review that made changes to the compat client for pep
18:35:28 <denis_makogon> #link https://review.openstack.org/#/c/54900/
18:35:42 <denis_makogon> i've updated review
18:35:44 <denis_makogon> today
18:36:02 <hub_cap> well i dont think weve made a decision on what to do denis_makogon
18:36:08 <denis_makogon> i took into accout all comments (alph. sort, etc)
18:36:24 <hub_cap> did u take into account why i -2'd it? :)
18:36:36 <hub_cap> which is why we are talking about compat.client ))
18:37:01 <hub_cap> so i -2'd it cuz we said compat.client would not be updated (well i thought so)
18:37:10 <hub_cap> but grapex has made a great point, that it is used
18:37:18 <hub_cap> its used in all our integration tests
18:37:20 <denis_makogon> hub_cap, -2 only for discuss
18:37:34 <hub_cap> for this discussion denis_makogon
18:37:44 <grapex> I talked to our boss and we'll probably get someone around Rax to update the int tests to use the newer stuff soon, and will also figure out a way to add the XML support into the newer code paths in an OpenStacky way.
18:37:45 <denis_makogon> yes =)
18:37:51 <grapex> Sometime this month hopefully.
18:38:07 <vipul> we still need the compat stuff to be able to do management api stuff
18:38:18 <hub_cap> grapex: ok cool. vipul good point
18:38:24 <denis_makogon> i only do PEP8 checks
18:38:24 <vipul> so until that's sorted out it seems fair to keep it up to date
18:38:30 <hub_cap> im ok w/ altering this since its still in use
18:38:32 <SlickNik> good point, vipul
18:38:42 <grapex> hub_cap vipul: Holy crap, there's no mgmt api stuff in the new CLI?
18:38:45 <hub_cap> altering = modifying the code
18:38:49 <hub_cap> since it is still used today
18:38:51 <vipul> grapex: you must not use it :p
18:38:54 <SlickNik> grapex: yes, that's the case.
18:38:57 <grapex> vipul: lol
18:38:58 <grapex> GUILTY
18:39:01 <SlickNik> lol
18:39:15 <hub_cap> grapex: not yet.. the v1 code is ther its just not in the cli
18:39:19 <robertmyers> who needs management anyway
18:39:20 <hub_cap> so u can still program to it
18:39:27 <grapex> Well we started using it a few weeks back, but only for non-mgmt stuff
18:39:28 <hub_cap> u just cant $trove blah....
18:39:35 <grapex> I figured it was general auth related shaningans
18:39:45 <grapex> Ok, then we'll try to add that in as well
18:40:03 <SlickNik> thx grapex.
18:40:07 <vipul> if that gets sorted out.. we should just nuke the compat code
18:40:14 <hub_cap> vipul: correct
18:40:18 <grapex> vipul: Agreed
18:40:40 <hub_cap> we can put it as a branch so that it is still around for someone to use it
18:40:49 <hub_cap> and NUKE it
18:40:55 <denis_makogon> lol
18:40:58 <SlickNik> vipul / hub_cap ++
18:41:05 <robertmyers> hub_cap: that is what Pypi versions are for
18:41:33 <hub_cap> robertmyers: fair enough, we can push one more update (itll tag the code in gh anyway)
18:41:38 <robertmyers> sure
18:41:47 <hub_cap> ok so, decision is that rax will clean up the mess i made
18:41:53 <robertmyers> hah
18:42:01 <esmute> seems fitting to me
18:42:02 <datsun_F40PH> more like hub_cap will clean up the mess you made
18:42:07 <datsun_F40PH> >:C
18:42:23 <hub_cap> #action datsun_F40PH to clean up the mess hub_cap made
18:42:27 <datsun_F40PH> #undo
18:42:30 <grapex> hub_cap: Lol
18:42:31 <SlickNik> lol
18:42:32 <hub_cap> i put a space
18:42:58 <hub_cap> wow i just refershed the wiki and its spinning... not loading
18:43:01 <hub_cap> whats the next topic?
18:43:04 <hub_cap> ah its up
18:43:06 <denis_makogon> yup
18:43:13 <hub_cap> #topic granular user privs
18:43:16 <hub_cap> datsun_F40PH: daz u
18:43:17 <datsun_F40PH> yes
18:43:20 <datsun_F40PH> i'd like to do it
18:43:24 <denis_makogon> go
18:43:29 <denis_makogon> ahead
18:43:29 <datsun_F40PH> and if nobody argues with my bp i'll do it like i've proposed
18:43:36 <hub_cap> link it plz
18:43:43 <denis_makogon> #link https://blueprints.launchpad.net/trove/+spec/user-privilege-control
18:43:52 <datsun_F40PH> there you go
18:44:07 * denis_makogon fast as bolt
18:44:24 <datsun_F40PH> well this is a good sign
18:44:40 <vipul> so currently the user we create has grant all
18:44:49 <vipul> why couldn't they do this via mysql
18:45:00 <datsun_F40PH> why couldn't they create users or dbs via mysql
18:45:10 <denis_makogon> vipul, +1
18:45:17 <vipul> fair enough
18:45:31 <vipul> i caution against re implemetnign more mysql specific things in our api
18:45:42 <datsun_F40PH> well this would be buried in mysql for now
18:45:44 <robertmyers> is this not an extrention?
18:45:45 <demorris> vipul: who says its MySQL only
18:45:51 <denis_makogon> but do we really need such functionality? i mean users, dbs ?
18:46:07 <vipul> well i don't mean mysql specific.. i should have said things you can do via the database protocol itself
18:46:14 <hub_cap> denis_makogon: this is an extension
18:46:18 <kevinconway> did somebody say users?!?
18:46:26 <robertmyers> kevinconway: shhh
18:46:27 <denis_makogon> i thought it came from Amazon RDS
18:46:30 <imsplitbit> oh heck
18:46:54 <datsun_F40PH> apparently it's been requested by users of our api at rax and i'd just like to implement it at least for mysql
18:47:25 <datsun_F40PH> since, cards on the table, i work at rax
18:47:26 <SlickNik> Seems to me that it would be different depending on the datastore_type. So seems like a datastore-specific extension.
18:47:34 <datsun_F40PH> of course it would
18:47:40 <datsun_F40PH> ask redis about users
18:47:50 <imsplitbit> NO USERS!!!
18:47:50 <datsun_F40PH> c:
18:47:51 <denis_makogon> SlickNik, +1
18:47:55 <imsplitbit> :0
18:47:57 <imsplitbit> :)
18:48:12 <denis_makogon> =[E]
18:48:15 <datsun_F40PH> so i seek to implement this as a mysql extension primarily
18:48:28 <vipul> i thought we were a provisioning api -- not a data api -- this is kinda in the middle
18:48:33 <hub_cap> there is no reason to argue about this
18:48:35 <demorris> since this is an extension, I am not sure that we need to have an argument over if it is needed or not
18:48:38 <hub_cap> weve talked about it a billion times
18:48:41 <hub_cap> this is an extension
18:48:49 <hub_cap> its not a core api
18:48:50 <hub_cap> moving on
18:48:51 <amcrn> datsun_F40PH: can you add this enhancement, but limit it to the user/databases extensions vs. adding it in instance-create?
18:49:15 <hub_cap> and kevinconway, no users
18:49:15 <denis_makogon> agreed with vipul, Data API is for Dynamo/Simple DB
18:49:25 <datsun_F40PH> amcrn: yeah i'm not a fan of the all-in-one instance create personally
18:49:31 <amcrn> excellente'
18:49:52 <hub_cap> amcrn: all-in-one instance create will probably not be in v2
18:49:53 <datsun_F40PH> so i'll only be messing with user calls
18:50:00 <vipul> we would also need a way of limiting which privileges are 'assignable'
18:50:03 <amcrn> hub_cap: hooray!
18:50:17 <demorris> the goal is not to duplicate the MySQL protocol, I get the arguments about creating a data API
18:50:18 <hub_cap> amcrn: unless someone can do it well, generic, not ugly
18:50:29 <hub_cap> :)
18:50:35 <hub_cap> ok core team
18:50:41 <hub_cap> do we approve this? im perfectly fine w/ it
18:50:51 <demorris> but for basic functionality around users and databases, there is value in exposing via the API as these are very common tasks when setting up the DB
18:50:52 <vipul> sure what the heck
18:50:58 <hub_cap> ill approve the BP if no one has concerns
18:51:00 <datsun_F40PH> i welcome discussion and suggestions in the appropriate places
18:51:03 <hub_cap> HAHAHAAHAHAH vipul
18:51:10 <amcrn> that's confidence!
18:51:14 <demorris> i would rather we debate how to implement it
18:51:20 <demorris> but I feel like most people don't care :)
18:51:36 <vipul> unfortunately we don't have a good way to turn off extensions
18:51:38 <vipul> so there's that
18:51:44 <hub_cap> vipul: fix it ;)
18:51:47 <datsun_F40PH> vipul: we can talk about permission masks
18:52:00 <vipul> datsun_F40PH: ok cool
18:52:18 <hub_cap> if u want to turn off all the extensons, just change the path.. likely if u dont want users extension, u wont want root or databases either :P
18:52:20 <vipul> hub_cap: yea will have to
18:52:28 <denis_makogon> i could take care of extensions
18:52:32 <hub_cap> yea i totaly agree its crap
18:52:33 <vipul> hub_cap: we don't want to turn off all
18:52:49 <hub_cap> denis_makogon: ok thats a good idea. its a big upgrade
18:52:55 <hub_cap> i want to see it done in multiple patchsets though
18:53:04 <hub_cap> 1000 lines of code in 1 patchset is too painful :)
18:53:07 <datsun_F40PH> so i'll begin to work on this
18:53:09 <amcrn> +1
18:53:18 <denis_makogon> hub_cap, ok
18:53:23 <hub_cap> datsun_F40PH: make sure it mirrors the way that nova/cinder/etc do it
18:53:26 <hub_cap> denis_makogon: ^ ^
18:53:29 <hub_cap> whoops datsun_F40PH
18:53:34 <hub_cap> ok lets move on then?
18:53:40 <datsun_F40PH> hub_cap: i'll consider it but my hands may be tied
18:53:48 <hub_cap> denis_makogon: there should already be a blueprint fyi
18:53:49 <denis_makogon> i'll do a bp for that
18:53:59 <vipul> thanks denis_makogon
18:54:05 <hub_cap> datsun_F40PH: your stuff will be ok... its not what denis is working on
18:54:07 <denis_makogon> refactoring for better pluggability ?
18:54:07 <datsun_F40PH> since we have a contract to uphold
18:54:25 <denis_makogon> those was mine
18:54:32 <datsun_F40PH> oh i see now
18:54:37 <hub_cap> ok moving on then?
18:54:40 <datsun_F40PH> please
18:54:40 <denis_makogon> yes
18:54:49 <hub_cap> #topic datastores fast follow
18:54:50 <hub_cap> amcrn: go go go
18:54:54 <amcrn> #link https://blueprints.launchpad.net/trove/+spec/datastore-type-version-followon
18:55:11 <amcrn> gist: there were a couple conversations around some enhancements to the datastores implementation
18:55:22 <amcrn> this is an attempt to catalog them
18:55:40 <amcrn> please add any additional concerns, comment on existing ones, etc.
18:55:50 <vipul> amcrn: this is great
18:56:02 <grapex> vipul: Agreed, good job amcrn.
18:56:05 <denis_makogon> amcrn, looks very cool
18:56:11 <amcrn> thanks
18:56:22 <cp16net> yeah its long there tho
18:56:35 <ashestakov_> vipul: are you ok with #2?
18:56:41 <cp16net> side note i think it should be in the wiki :-P
18:56:47 <amcrn> cp16net: i sell cliffnotes for $5 ;)
18:57:00 <cp16net> damn you are a business man huh?
18:57:01 <cp16net> :-P
18:57:10 <amcrn> gotta be on that hussle
18:57:12 <hub_cap> amcrn: he actually sells notes that a homeless dude named cliff writes
18:57:16 <cp16net> haha
18:57:48 <vipul> ashestakov_: yep i think that's what we agreed
18:58:00 <hub_cap> yes so someone should really do that work!
18:58:07 <ashestakov_> vipul: you pushed on me to do this way :)
18:58:51 <vipul> yea i think we agreed to follow-up on that.. and this looks like the follow-up we need
18:58:51 <hub_cap> ok 2 min left... anyone gonna claim that?
18:58:54 <denis_makogon> so, could we move on ?
18:59:11 <amcrn> ashestakov_: you mentioned last night you'd like to work on these?
18:59:17 <denis_makogon> https://review.openstack.org/59231 - this bad broken code was merged =/
18:59:29 <ashestakov_> amcrn: yes, but i have some questions about this
18:59:40 <hub_cap> ok
19:00:05 <hub_cap> #action ashestakov_ to do the follow up datastores work
19:00:09 <hub_cap> ok gotta end meeting
19:00:12 <hub_cap> #endmeeting