20:00:18 <hub_cap> #startmeeting trove
20:00:22 <openstack> Meeting started Wed Jul 24 20:00:18 2013 UTC.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:25 <openstack> The meeting name has been set to 'trove'
20:00:39 <vipul> \o/
20:00:46 <robertmyers> o/
20:00:49 <pdmars> o/
20:00:49 <hub_cap> lets give a min
20:01:00 <KennethWilke> hi
20:01:06 <earthpiper> ello
20:01:24 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
20:01:25 <datsun180b> hello
20:01:27 <kevinconway> 7o
20:01:33 <hub_cap> #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-07-17-20.00.html
20:01:37 <hub_cap> #topic action items
20:01:50 <hub_cap> heh so AI's will be quick
20:01:56 <imsplitbit> o/
20:01:57 <hub_cap> vipul: any doc update on the wiki?
20:02:02 <grapex> o/
20:02:05 <vipul> hub_cap: done!
20:02:07 <hub_cap> ive moved every page ive looked at
20:02:09 <imsplitbit> yay!
20:02:09 <vipul> see https://wiki.openstack.org/wiki/Trove
20:02:09 <hub_cap> done?
20:02:12 <hub_cap> i moved two today
20:02:18 <hub_cap> oh done w/ that page
20:02:20 <SlickNik> o/
20:02:21 <hub_cap> cool
20:02:28 <vipul> are there more pages that got lost?
20:02:33 <hub_cap> oh ya vipul tons
20:02:33 <vipul> moved a bunch of them as well
20:02:35 <hub_cap> the next one i think we covered eh?
20:02:35 <hub_cap> search reddwarf
20:02:39 <hub_cap> or red dwarf
20:03:03 <hub_cap> anyhoo we can just update as we see fit
20:03:10 <hub_cap> its for older stuff anyway
20:03:21 <hub_cap> like i did configuration editing today cuz a mirantis guy asked me about it
20:03:34 <hub_cap> so i thikn the next AI is already taken care of eh?
20:03:42 <hub_cap> Stop test and Unsuccessful Restart test thing
20:03:49 <hub_cap> we decided to move it out of bb testsing
20:03:56 <cp16net> \o
20:04:10 <grapex> Yep
20:04:22 <hub_cap> =o= four arm me
20:04:28 <hub_cap> or my top gun pin
20:04:38 <hub_cap> ok cool lets move on then
20:04:45 <hub_cap> im going ot leave the api discussion to last
20:04:51 <hub_cap> so ill skip to imsplitbits topic
20:04:53 <cp16net> \^o
20:04:59 <cp16net> my muscles
20:05:02 <cp16net> lol
20:05:03 <hub_cap> lol cp16net
20:05:05 <hub_cap> #topic Replication API update
20:05:17 <hub_cap> so imsplitbit tell us about replication api
20:05:47 <imsplitbit> well we made the concensus
20:06:00 <imsplitbit> that we were going to use /clusters as a helper for cluster ops
20:06:06 <imsplitbit> instance ops stay in /instances
20:06:09 <djohnstone> o/
20:06:16 <imsplitbit> I've begun work on the /clustertypes
20:06:25 <imsplitbit> which is "flavors for clusters"
20:06:33 <hub_cap> cool
20:06:35 <imsplitbit> thats about all I have at this point
20:06:36 <hub_cap> thats a good way to put it
20:06:39 <hub_cap> ok great
20:06:51 <hub_cap> now for the topic at hand
20:06:58 <hub_cap> the hp guys dont know much about this yet so
20:07:03 <imsplitbit> I HATE IT
20:07:04 * hub_cap makes vipul read the Windows ME user guide
20:07:04 <imsplitbit> lol
20:07:11 <imsplitbit> wanted to start early :)
20:07:11 * hub_cap pokes SlickNik
20:07:16 <vipul> windows fun!
20:07:26 <KennethWilke> 3.1 is better
20:07:26 <imsplitbit> ouch
20:07:26 * SlickNik wakes up
20:07:28 <hub_cap> vipul: SlickNik take a minute to read
20:07:30 <imsplitbit> ME...
20:07:37 <hub_cap> #topic capabilities
20:07:40 <hub_cap> #link https://wiki.openstack.org/wiki/Trove/extensionsrefactor
20:07:53 <hub_cap> i prefer to use the term capabilities to extension earthpiper
20:07:55 <hub_cap> fwiw
20:08:08 <earthpiper> sho nuff
20:08:11 <hub_cap> lets give till 20:10 to finish reading it and talk about the pro/con
20:08:29 <earthpiper> brb
20:08:30 <earthpiper> then
20:08:39 <kevinconway> hub_cap: 20:10 central standard time right?
20:08:45 <hub_cap> heh yes kevinconway
20:08:47 <hub_cap> not utc
20:08:52 <KennethWilke> ...
20:08:55 <KennethWilke> i only take epoch
20:08:59 <kevinconway> so for the next five hours?
20:09:04 <hub_cap> Wed Jul 24 20:08:27 UTC 2013
20:09:15 <hub_cap> u have 1 1/2 minute to keep annoying me kevinconway
20:09:21 <hub_cap> ;)
20:09:36 <kevinconway> its 15:10 CST
20:09:40 <kevinconway> why is time so confusing?
20:09:50 <hub_cap> cuz in openstack u only speak in utc
20:09:52 <grapex> hub_cap: Would it be bad form to add to that wiki article at this time?
20:10:05 <hub_cap> grapex: ummm yes
20:10:08 <hub_cap> well no
20:10:09 <KennethWilke> i want integer epoch timestamps, or you do it right!
20:10:11 <hub_cap> but no one would read it
20:10:14 <KennethWilke> :)
20:10:37 <hub_cap> but its ok grapex to do that because u wnt the information to persist
20:10:41 <hub_cap> so go for it
20:10:48 <hub_cap> u can always interject those points when relevant
20:11:09 <KennethWilke> link us your diff!
20:11:25 <hub_cap> LOL just click history
20:11:42 <hub_cap> ok vipul SlickNik have a feel for whats going on?
20:11:46 <hub_cap> earthpiper: back?
20:11:50 <SlickNik> yeah
20:11:51 <vipul> kinda
20:11:56 <hub_cap> kevinconway: happy that we are in utc time?
20:11:58 <KennethWilke> hub_cap: he is afk
20:12:04 <hub_cap> k
20:12:09 <vipul> so we want to dynamically load a service.py based on service_type?
20:12:16 <hub_cap> so yes
20:12:18 <cp16net> i'm never in utc time
20:12:18 <hub_cap> but its more than that
20:12:32 <hub_cap> its dynamically load the api based on service_type
20:12:37 <KennethWilke> i think we want to consider the impact to the api over implementation at this moment
20:12:51 <hub_cap> as in, /instances/id/users changes payload based on what type your instance is
20:12:51 <KennethWilke> if i understand correctly
20:12:59 <vipul> hmm
20:13:03 <hub_cap> correct KennethWilke
20:13:22 <SlickNik> so not just guestagent, but the trove-api as well.
20:13:25 <hub_cap> lets hold off on opinions till earthpiper gets back
20:13:28 <hub_cap> correct SlickNik
20:13:47 <earthpiper> yeah
20:13:48 <hub_cap> the arguments are 1) the user shuldnt care that he has a redis type, he should just pass info to /users (yes bad example)
20:13:50 <vipul> So .. isn't it kinda odd that the body would change based on a type of database?
20:13:56 <imsplitbit> you cannot have an opinion unless earthpiper is present???
20:14:04 <hub_cap> no imsplitbit u cannot
20:14:07 <imsplitbit> lol
20:14:07 <hub_cap> he is driving this
20:14:14 <KennethWilke> vipul: i think so
20:14:14 <hub_cap> go earthpiper (pips)
20:14:24 <hub_cap> the input/output can differ based on the capability
20:14:26 <SlickNik> btw, hello earthpiper!
20:14:36 <earthpiper> Hi I am Conrad at Rackspace.
20:14:42 <datsun180b> oh that makes sense now
20:14:44 <vipul> howdy
20:14:55 <earthpiper> If you don't know my net handle =)
20:15:18 <KennethWilke> hello, i am kenneth at rackspace
20:15:22 <KennethWilke> just... in case
20:15:30 <imsplitbit> greetings
20:15:33 <imsplitbit> ok go
20:15:49 <hub_cap> he is the only Kenneth at rackspace
20:15:55 <imsplitbit> lol
20:15:58 <datsun180b> what's the frequency
20:16:02 <kevinconway> Hello, I am Inigo Montoya… You killed my father.
20:16:03 <hub_cap> LOL
20:16:06 <imsplitbit> earthpiper: go
20:16:09 <hub_cap> srsly GO
20:16:10 <hub_cap> GO GO GO
20:16:18 <hub_cap> weve burned 6 minutes on intros :)
20:16:22 <imsplitbit> exactly
20:16:23 <earthpiper> So what do you guys think?
20:16:26 <hub_cap> no
20:16:32 <imsplitbit> I think that sushi sounds great
20:16:33 <SlickNik> hub_cap: trying to understand the motivation for this...
20:16:37 <hub_cap> tell us what you think earthpiper
20:16:40 <earthpiper> Oh cool.
20:16:42 <earthpiper> Thanks
20:16:55 <hub_cap> SlickNik: earthpiper will explain
20:17:03 <hub_cap> what is the motivation earthpiper
20:17:13 <earthpiper> So.. the problem with current extensions is they load everything in that directory.
20:17:21 <earthpiper> We want Trove to support more Databases.
20:17:30 <earthpiper> and right now the application is rather monolithic.
20:17:42 <hub_cap> lets stick to the api earthpiper
20:17:43 <hub_cap> not the impl
20:17:49 <hub_cap> the why so to speak
20:18:24 <juice> i have a high level question
20:18:27 <earthpiper> You get a routing conflict with current extensions if you have different requirements for instances functions.
20:18:33 <hub_cap> correct
20:18:44 <earthpiper> So like Users for postgres users for mysql etc.
20:18:44 <hub_cap> so /users doesnt make sense if you host > 1 database type in the same installation
20:19:02 <KennethWilke> or on my redis boxen
20:19:04 <hub_cap> how do u differenciate between postgres' users and mysql users
20:19:13 <hub_cap> the one u add users too KennethWilke ;)
20:19:22 <vipul> are they really different types of users?  they are 'database' users
20:19:22 <hub_cap> juice: this is irc, ask away
20:19:26 <imsplitbit> assuming we will allow a redis and mysql install on one instance yes?
20:19:34 <juice> yeah I am formulating it :)
20:19:37 <hub_cap> one installation imsplitbit
20:19:39 <hub_cap> not one instnace
20:19:41 <esp> regarding the bit about different POST body's in the API will the POST body's still follow the same structure even though they will be different?
20:19:43 <KennethWilke> they may have different parameters based on database implementation
20:19:48 <KennethWilke> or requirements
20:20:00 <imsplitbit> ok one aggregated infrastructure to manage all dbs
20:20:03 <hub_cap> yes for instance postgres requires a default db, from what i think jeffe said
20:20:03 <juice> what level of abstraction do we want for trove or what level of abstraction do we think is most suitable for trove
20:20:03 <earthpiper> Well we should not make a person only host one type of db system per cluster.
20:20:13 <hub_cap> and this is more than just /users its /anything
20:20:25 <KennethWilke> /db_specific_feature
20:20:28 <hub_cap> correct
20:20:33 <hub_cap> it could be /flushkeys for redis
20:20:34 <juice> is that we plan on configuring trove at deploy time for a specifc implementation and have it build those instance types
20:20:34 <hub_cap> ;)
20:20:49 <hub_cap> juice: it shoudl be able to handle > 1 service_type
20:20:51 <hub_cap> in the same api
20:20:53 <juice> or is trove supposed to standup and handle any db implementation type
20:21:02 <hub_cap> you configure it juice
20:21:02 <vipul> so there are two types of things...
20:21:06 <hub_cap> to handle what u want to support
20:21:18 <hub_cap> avail_types=postgres, mysql, percona, redis
20:21:20 <hub_cap> so to speak
20:21:21 <vipul> additional operations on a db_type.. .which is differnt from the same operation, but different request for db_types
20:21:37 <juice> and from the end user do they know which service type they are getting
20:21:42 <hub_cap> yes so same uri, different body
20:21:43 <vipul> I think we can support db_type specific actions
20:21:47 <hub_cap> sound familar?
20:21:47 <juice> we don't allow them currently to specify the service type on boot
20:21:54 <hub_cap> /actions {}
20:22:02 <jcooley> the thing is, if you are managing multiple databases with the same infrastructure, what are you gaining if each one has a completely different command-implementation?
20:22:13 <grapex> vipul: I don't know- so far it seems like the users call has had to change a lot. We've added things to it and then found out it was ambigious because of how MySQL worked. Maybe I've mistinterpretted what you're saying, but I can't imagine users would "just work" for all db types.
20:22:17 <SlickNik> juice: this proposal seeks to change that, I think.
20:22:17 <hub_cap> technically juice we do
20:22:18 <jcooley> i mean, why not just clone the 5 or 6 nodes
20:22:33 <hub_cap> pass service_type in to the create, and watch it go
20:22:40 <jcooley> right,
20:22:54 <jcooley> if it doesn't work for a set of common types, why force a common infrastructure?
20:22:56 <hub_cap> what benefit does having a bunch of duplicate api nodes w/ a single config diffence buy you jcooley?
20:23:03 <hub_cap> its gonna be the same codebase
20:23:14 <jcooley> i dunno, i have different api nodes for nova, swift, savanna, ...
20:23:16 <hub_cap> so the difference between 6 nodes is gonna be service_type=blah
20:23:21 <vipul> grapex: Right, so I agree there may be differences, and I think instead of a body that's compeletely different for different databases, we come up with either a genericized API that works across, or we make things optional
20:23:22 <juice> ok so the user specified the service type and they are now wanting to interact with a redis or postgres instance
20:23:38 <KennethWilke> jcooley: but you should be able to spin up ubuntu and centos or whatever on one nova deployment
20:23:42 <earthpiper> This is just to make the deployment of new db types easier.
20:23:53 <jcooley> right, with the same api
20:24:00 <KennethWilke> on the same boxes if you would like
20:24:05 <earthpiper> or not like
20:24:10 <jcooley> well, that's where i'm getting lost
20:24:10 <earthpiper> you can do what you want with it
20:24:26 <grapex> vipul: I think having a generic user call won't be satisfying for power users, unless we offer it in addition to a type specific call
20:24:29 <datsun180b> so even if not every db has a concept of users, ideally they'll all have a concept of connections. is that a common ground we can build off of?
20:24:40 <hub_cap> not really
20:24:41 <hub_cap> take redis
20:24:43 <grapex> So there could be a user create call specific for MySQL, but then we could make a generic one for any DB.
20:24:43 <hub_cap> no users at all
20:24:44 <jcooley> sure, flexibility is nice but i'm not seeing the code sharing.
20:24:44 <hub_cap> nil
20:24:48 <jcooley> only infrastructure sharing.
20:24:48 <KennethWilke> users?
20:24:51 <earthpiper> It returns 404
20:24:55 <earthpiper> rather than a 200
20:25:04 <earthpiper> because that route is not defined for redis
20:25:05 <hub_cap> so do we, since redis can support resizes, resets, all the things trove /instances support
20:25:14 <hub_cap> do we have to stand up a diff service to host it?
20:25:32 <hub_cap> and do we need a different docbook altogether?
20:25:37 <hub_cap> just so we can have separate services?
20:25:39 <vipul> hub_cap: No, i think it's fine to return not-implemented if things don't match
20:25:48 <vipul> but that not impelemtned should come from the Guest Agent
20:25:53 <hub_cap> i dont agree
20:25:54 <vipul> which determines whether that operation can be done or not
20:25:59 <hub_cap> id prefer to return "there is no route for this"
20:26:01 <KennethWilke> i think not implemented should be returned by the api
20:26:17 <datsun180b> more informative than a 404
20:26:22 <hub_cap> the same thing when you pass /instances/id/honeybooboo
20:26:22 <vipul> exactly
20:26:25 <grapex> Yeah, we don't want the guest agent to have to be that intelligent about what the API can do.
20:26:28 <cp16net> yeah not implemented doesnt sound like something that should be returned
20:26:37 <jcooley> i like vipul's idea of placing the differences in the guest agent...
20:26:38 <vipul> why is it that they can invoke the same route at the same endpoint in oen case but not the other
20:26:43 <juice> jumping to solutions here but what comes to mind is that each database would have it's own discrete api command structure and TROVE simply becomes a router to the different api implementations
20:27:02 <hub_cap> juice: that is one of the approaches
20:27:02 <SlickNik> grapex: but the guest agent needs to be intelligent about what the API can do since the guestagent will be the one doing it!
20:27:03 <kevinconway> hub_cap: 501 Not Implemented
20:27:15 <juice> you might even extend that and have different instances of task manager out there for the various implementations
20:27:17 <grapex> juice: That's my favorite idea, with the addition that you'd have a generic instance resource that could do actions that were performable by any db type
20:27:23 <hub_cap> naw taskmgr shoudl be generi
20:27:24 <hub_cap> c
20:27:44 <juice> this approach allows you to keep a generic front end yet have documentable and implementation specific apis
20:27:48 <hub_cap> the big differences are the api+guest impl
20:27:54 <grapex> SlickNik: Of course, but the guest agent shouldn't have to understand someone made a request for a Redis operation and the server is MySQL
20:28:00 <vipul> juice: that means Trove has many APIs
20:28:03 <hub_cap> stop typing
20:28:03 <grapex> The API should know that and not even ask the guest agent
20:28:12 <hub_cap> do we agree that trove can host > 1 capability
20:28:17 <KennethWilke> yes
20:28:19 <vipul> yes
20:28:20 <earthpiper> yes
20:28:21 <grapex> yes
20:28:24 <kevinconway> #vote yes
20:28:25 <hub_cap> good
20:28:26 <robertmyers> yes
20:28:28 <cp16net> yes
20:28:31 <cp16net> #voted
20:28:34 <hub_cap> i can start a vote kevinconway ;)
20:28:35 <vipul> o/
20:28:41 <hub_cap> ok good
20:28:42 <SlickNik> #agreed
20:28:43 <hub_cap> lets move on
20:28:47 <KennethWilke> #done
20:28:49 <hub_cap> now its a matter of the proposal
20:28:57 <hub_cap> do we 1) dynamically change the route
20:29:02 <hub_cap> or 2) define namespaces for the routes
20:29:23 <vipul> i see 3 things here...
20:29:23 <KennethWilke> 2
20:29:26 <hub_cap> 1 is potentially more confusing for the user (imho) and 2 is potentially more annoying for the user (since there is 1 type)
20:29:31 <jcooley> grapex: disagree.
20:29:33 <hub_cap> whats 3?
20:29:35 <vipul> 1. choosing which extensions should be loaded instead of all
20:29:41 <vipul> 2. dynamic route / dynamic body
20:30:04 <vipul> 3. fixed route w/namespaced route
20:30:04 <jcooley> api should not have all the intelligence or we have to bake the polymorphism into it
20:30:09 <hub_cap> hold up vipul
20:30:16 <hub_cap> 1 is a installation procedure
20:30:23 <hub_cap> and 2/3 are the api differnces
20:30:27 <grapex> I think we agreed 1 wasn't an option if there's >1 capability
20:30:37 <hub_cap> 1 will happen
20:30:37 <earthpiper> Correct grapex
20:30:44 <esp> hub_cap: is 2) above basically defining new routes for each db type?
20:30:47 <vipul> ok.. makes sense
20:30:54 <KennethWilke> esp: yes
20:30:56 <hub_cap> u will choose the types you want to run based on your needs
20:31:09 <hub_cap> avail_types=cassandra,oracle,couchdb
20:31:15 <esp> KennethWilke: thx.  yeah I like that better.
20:31:17 <juice> we should revise that original vote to say "trove should dynamically support > 1 impl at runtime"
20:31:25 <KennethWilke> esp: yw :)
20:31:27 <grapex> juice: Good idea
20:31:33 <hub_cap> huh!?!?
20:31:34 <hub_cap> no
20:31:35 <vipul> i'm ok with dyanmically loading a route in the backend, but i am not ok with those supporting differnt bodies
20:31:38 <cp16net> 2: means to me that you dynamically look up the instance type and do the work
20:31:42 <hub_cap> it was jcooley that brought up to not support > 1
20:31:46 <vipul> i can see that we may have different validation rules for a db_type
20:31:47 <cp16net> 3 means that its defined in the uri
20:31:54 <hub_cap> we are getting out of hand
20:31:56 <vipul> but the request body shoudl be the same/similar
20:31:56 <hub_cap> let me rephrase
20:31:59 <KennethWilke> cp16net: in any other case do you not need to know the instance type if trove supports multiple dbs?
20:32:04 * hub_cap bangs the gavel
20:32:05 <jcooley> hub_cap: only meant that if they're really different and you can't share implementation, you're not gaining anything.
20:32:21 <hub_cap> we will support > 1 impl in the same codebase/install/api server
20:32:22 <hub_cap> period
20:32:33 <hub_cap> if you want cassandra and redis, you can get them
20:32:33 <hub_cap> thats not being argued
20:32:34 <grapex> vipul: I decided I couldn't stand the totally dynamic, every type uses the same request path idea when I realized different db_types would eventually have different bodies for the same request paths.
20:32:45 <hub_cap> if u have to restart the api server to install a new type, thats fine
20:32:50 * hub_cap bangs the gavel and points at grapex
20:32:57 <KennethWilke> grapex: i agree
20:33:12 <hub_cap> lol netsplit
20:33:16 <grapex> hub_cap: Am I in contempt?
20:33:19 <hub_cap> yes
20:33:20 * KennethWilke shame
20:33:21 <hub_cap> :P
20:33:26 <vipul> you have the floor hub_cap
20:33:33 <hub_cap> so the question is this
20:33:47 <imsplitbit> NO
20:33:49 <hub_cap> do we have an api that supports dynamic bodies, because we cannot guarantee that every call to /users will be the same
20:34:00 <imsplitbit> I just wanted to be in contempt too :)
20:34:03 <hub_cap> or do we support namespaced urls, where the payload is the same
20:34:19 <grapex> hub_cap: May I approach the bench?
20:34:21 <hub_cap> but you have to type the type in
20:34:24 <hub_cap> grapex: aye
20:34:32 <earthpiper> I got dibs next.
20:34:39 <hub_cap> yes you do earthpiper
20:34:42 <imsplitbit> then me
20:34:46 <KennethWilke> then i!
20:34:48 <hub_cap> no imsplitbit
20:34:50 <hub_cap> never
20:34:52 <grapex> Another thing to consider is in addition to namespaced requests for specific types, we could also make requests to the existing instances path w/o the db_type to do things which *ANY* instance could do
20:34:54 <imsplitbit> damnit
20:35:06 <grapex> Think of it like calling a super class's interface
20:35:18 <hub_cap> it will, resizes will still go thru /instance/id
20:35:23 <hub_cap> /instance/id/resize
20:35:25 <hub_cap> NO ACTIONS
20:35:36 <imsplitbit> but we all *love* actions
20:35:46 <grapex> Those are our favorite!!
20:35:48 <juice> disagree
20:35:57 * juice notes sarcasm
20:35:59 <hub_cap> /instance/id/resize, /instances/id/user vs /instances/id/mysql/user, /instances/id/user vs /instances/id/redis/user
20:35:59 <grapex> But they're so hard to use... :(
20:36:07 <grapex> j/k
20:36:11 <grapex> Put me back in contempt
20:36:19 <earthpiper> So can I interject really quick.
20:36:22 * hub_cap urges grapex to use Windows Millennium Edition
20:36:27 <esp> I think it would be less redundancy (in your DTO or value objects) if request payloads and response payloads are the same across db_types.
20:36:28 <hub_cap> earthpiper: plz do
20:36:31 <earthpiper> Ok
20:36:37 <earthpiper> take a gander at client flows
20:36:41 <earthpiper> at the bottom of the propsal
20:36:44 <earthpiper> https://wiki.openstack.org/wiki/Trove/extensionsrefactor
20:36:44 <hub_cap> esp: we cant guarantee that
20:36:48 <SlickNik> hub_cap: While I love the idea, I'm worried that this opens up the opportunity for the APIs of the different implementations to diverge to a point where they look like completely different APIs. This means that as a consumer, I have to relearn / re-work the API every time I need a different type of instance. This seems like a serious disadvantage for a managed db solution, which should make my life easier by providing somewhat of a consiste
20:37:04 <esp> hub_cap: nope but it's a good place to start.
20:37:05 <grapex> esp: You could of course reuse classes that were similar as base objects between the request bodies of various types.
20:37:18 <vipul> SlickNik: +1
20:37:21 <imsplitbit> SlickNik: +1
20:37:28 <hub_cap> im not sure what SlickNik is saying
20:37:32 <hub_cap> voting for #1 or #2?
20:37:36 <KennethWilke> 1 i believe
20:37:37 <vipul> neither
20:37:42 <hub_cap> or voting against to ever have /usrs
20:37:45 <datsun180b> so i have a half-baked idea wrt to marrying namespaces and dynamic
20:37:47 <grapex> SlickNik: Do you mean a user switching between MySQL and Percona or something similar like that?
20:37:58 <SlickNik> not taking a side of the #1 or #2 fence yet.
20:38:08 <KennethWilke> may i?
20:38:16 <hub_cap> i dont think earthpiper got to interject
20:38:20 <hub_cap> he just said go read some shit
20:38:22 <KennethWilke> earthpiper: gogogog
20:38:23 <earthpiper> So the problem is
20:38:27 <earthpiper> If we support other databases
20:38:29 <earthpiper> stuff changes
20:38:31 <esp> grapex: agreed but I guess I'd like to see how different each imp will be to say for sure
20:38:31 <earthpiper> peroid
20:38:36 <vipul> If we have a single endpoint, and a single API... why would someone be required to figure out what the body or URI shoudl be based on a type
20:38:59 <earthpiper> vipul: that does not matter
20:39:05 <earthpiper> how else would you do it?
20:39:09 <earthpiper> Different DB
20:39:16 <earthpiper> means a possible different contract to do stuff
20:39:26 <imsplitbit> vipul: +1
20:39:30 <vipul> You have a genericized body
20:39:34 <grapex> I think the issue is, we're going between MySQL and NoSQL so stuff is going to change
20:39:35 <vipul> say someone  is using Java
20:39:36 <robertmyers> why don't we just remove the ability to create users?
20:39:42 <robertmyers> done
20:39:43 <grapex> I think between SQL db's things could be similar
20:39:48 <vipul> they are likely going to be bulidng a object model of our request /responses
20:39:48 <KennethWilke> grapex: +1
20:39:51 <hub_cap> robertmyers: you just made our director cry
20:39:51 <grapex> What if we had, in addition to "mysql/instances/<instance_id>" and "postgres/instances/<instance_id>", a "sql/instancs/<instance_id>" which was a subset.
20:40:00 <vipul> they are going to be required to build new object models evyer time we add another db?
20:40:07 <grapex> Uses could use "sql" if they didn't care about MySQL specific details
20:40:12 <datsun180b> well for dbs that don't have users, how do you get your data to and from the db?
20:40:18 <hub_cap> sure but i think u have it backwards grapex
20:40:20 <imsplitbit> datsun180b: I like your concept of "connection"
20:40:26 <earthpiper> datsun180b: reddis does not support usetrs
20:40:28 <KennethWilke> datsun180b: redis exists
20:40:31 <earthpiper> redis*
20:40:34 <hub_cap> instances/id/mysql vs instances/id/sql
20:40:43 <earthpiper> but it does support backups
20:40:45 <datsun180b> do you communicate with redis via telepathy
20:40:48 <grapex> vipul: Not if we were smart and made our schema use superclasses appropriately. The amount of changes could be minimized.
20:40:50 <vipul> I still feel like there are different ways to handle thigns that service types do not support
20:40:51 <KennethWilke> nope, sockets
20:40:55 <earthpiper> only sockets.
20:40:57 <hub_cap> user sockets
20:40:57 <datsun180b> so, a connection
20:40:58 <hub_cap> :P
20:41:02 <earthpiper> Oh
20:41:09 <kevinconway> so /instances/id/sockets
20:41:12 <earthpiper> So we switch userrs to connections...
20:41:26 <hub_cap> ok lets stop talking about users
20:41:31 <KennethWilke> thank you!
20:41:33 <hub_cap> lets talk /flushkeys
20:41:33 <KennethWilke> :)
20:41:34 <datsun180b> instances/id/connections
20:41:38 <grapex> Or rather, instances/id/users, whose request body is a subset of mysql/instances/id/users...
20:41:46 <hub_cap> the goal here is _NOT_ to solve /users
20:41:48 <imsplitbit> hub_cap: lets talk /flush
20:41:52 <hub_cap> its to solve /any_db_operation
20:42:01 <imsplitbit> which applies to much more than redis or mysql or postgres
20:42:02 <hub_cap> /rebalance_ring
20:42:03 <datsun180b> where for mysql dbs instances/id/connections is an alias for instances/id/mysql/users
20:42:08 <datsun180b> maybe a 301 MOVED PERM
20:42:17 <hub_cap> datsun180b: lets not reinvent users
20:42:22 <hub_cap> this is not a conversation about users
20:42:36 <hub_cap> its a conversation about /anything for a specific db
20:42:37 <datsun180b> i'm using it as an example to build a common ground
20:42:38 <earthpiper> we don't need to fix users. we need to fix the routing for DB specific stuff.
20:42:39 <vipul> having additional DB operations is totally fine -- leave it to guest agent to determine whether it's something it can act on or not
20:42:56 <earthpiper> vipul: how do you pass it the message then?
20:43:02 <earthpiper> Without extending the API interface
20:43:09 <earthpiper> so the user agent knows it is being passed that?
20:43:13 <earthpiper> How is that possible?
20:43:14 <hub_cap> sure so you will have /instances/id/rebalance
20:43:16 <vipul> you'd have to have a common rpc_api across all guest agents
20:43:20 <juice> can we do internal rerouting/redirects
20:43:23 <vipul> but the mysql_impl will decide it's not possible
20:43:26 <earthpiper> How does the user
20:43:27 <grapex> Again, why make the guest agent determine the type? The API knows the type and shouldn't even bother. In fact, it should validate that the user made a bad request well before considering talking to the guest.
20:43:32 <hub_cap> see to me thats ugly vipul
20:43:37 <earthpiper> wait
20:43:44 <hub_cap> every guest has to impl, optionally, ANY call that ANY db can do?
20:43:44 <earthpiper> It's not the matter of it being ugly
20:43:49 <KennethWilke> vipul: i don't think the api should shove anything the user gives it into rabbit
20:44:02 <datsun180b> i foresee a lot of noops hub_cap
20:44:19 <earthpiper> It's a matter of how do you do it without extending the user api
20:44:20 <vipul> fine, we can block that at the API level
20:44:27 <vipul> with policy based config or something
20:44:31 <earthpiper> No
20:44:32 <hub_cap> ya datsun180b
20:44:33 <vipul> that's not the point
20:44:36 <earthpiper> how can the user send the message?
20:44:48 <earthpiper> To do whatever you want?
20:44:50 <hub_cap> to /instances/id/something
20:45:00 <earthpiper> You have to extend the user api
20:45:06 <vipul> the user will see a consistent API with every available 'operatation'
20:45:07 <earthpiper> period.
20:45:07 <hub_cap> obvi :)
20:45:21 <grapex> How about /instances/id/void redirects dynamically to the typed request path. :)
20:45:23 <hub_cap> see id rather have namespaced apis w/ capabilities
20:45:25 * juice is reading earthpipers proposal
20:45:38 <hub_cap> mysql/ can do users, schemas, and making_coffee
20:45:45 <juice> did we all have a chance to think about this before coming to the meeting
20:45:52 <KennethWilke> no
20:45:52 <hub_cap> cassandra/ can do rebalance_ring, users and making_donuts
20:45:53 <vipul> not really :)
20:45:54 <KennethWilke> but i did
20:45:55 <KennethWilke> :)
20:46:01 <juice> perhaps we have bantered enough and need some time to give it some self-reflection and come back to this
20:46:04 <KennethWilke> because i do not want to use trove for redis
20:46:05 <SlickNik> earthpiper: I think the idea is to extend the API to every possible operation. And let the guestagent decide if it supports it or not. Not sure I like that….
20:46:07 <KennethWilke> i mean mysql** sorrty
20:46:07 <hub_cap> redis/ CANT DO USERS (god tina eat your food - napolean voice)
20:46:08 <KennethWilke> lol
20:46:18 <imsplitbit> juice: I agree
20:46:20 <vipul> juice: +1 i don't think we have enough background really to be able to make a call
20:46:28 <hub_cap> u know i feel thats valid
20:46:28 <earthpiper> SlickNik: I don't like that idea either.
20:46:35 <hub_cap> can we meet tomorrow to discuss?
20:46:47 <grapex> hub_cap: Google hang outs?
20:46:49 <imsplitbit> I am still a fan of simple generic api and internally we route/return the right stuff
20:46:55 <juice> works for me
20:47:02 <vipul> imsplitbit: +1 that's what i was leading towards..
20:47:03 <hub_cap> i was thinking irc grapex
20:47:10 <KennethWilke> i think irc as well
20:47:11 <vipul> the user should see consistency
20:47:15 <imsplitbit> this /sql /nosql /mysql /postgres thing seems to be too confusing for the end user to me
20:47:19 <datsun180b> if only we had a channel we were all on all day together
20:47:24 <grapex> hub_cap: Seems like short notice
20:47:25 <hub_cap> see vipul id argue that /users w/ different payloads is _not_ consistant
20:47:26 <SlickNik> I'd like to think about this some more as well. +1 to meeting tomorrow.
20:47:28 <KennethWilke> consistency seems hard unless we offer consistent technologies behind trove
20:47:31 <grapex> hub_cap: Maybe a bit later?
20:47:32 <hub_cap> but /mysql/users is
20:47:42 <grapex> We can all add to the wiki in the meanwhile
20:47:42 <KennethWilke> and redis != mysql != mongo != thing not yet made we want in trove
20:47:44 <hub_cap> do we need > 24 hrs to ruminate on this grapex?
20:47:52 <vipul> hub_cap: but then you have postgres/users == mysql/users pretty much
20:47:52 <hub_cap> or is your shcedule booked tomorrow?
20:47:54 <imsplitbit> hub_cap: stop talking users!!!!!!!!!!!!!!!!
20:47:56 <imsplitbit> :)
20:47:59 <hub_cap> vipul: sure
20:47:59 <grapex> hub_cap: Hey I know what I want
20:48:00 <juice> does anyone know of resource for various api commands
20:48:03 <hub_cap> for USERS
20:48:04 <hub_cap> exactly imsplitbit
20:48:11 <juice> like a digital copy of 7 databases in 7 weeks
20:48:20 <imsplitbit> when I said users I meant "consumers of the api"
20:48:26 <kevinconway> #topic users
20:48:30 <imsplitbit> lol
20:48:32 <SlickNik> lol
20:48:38 <hub_cap> sorry kevinconway you dont have that power
20:48:50 <grapex> kevinconway: LOL!
20:48:55 <imsplitbit> /ban hub_cap
20:48:58 <imsplitbit> lol
20:49:02 <hub_cap> imsplitbit: even i dont have that power
20:49:08 <hub_cap> i wouldve kicked u alreay
20:49:15 <imsplitbit> fo rill
20:49:23 <imsplitbit> ok lets keep talking about this
20:49:28 <hub_cap> naw lets not
20:49:31 <imsplitbit> maybe not today
20:49:32 <hub_cap> lets thikn it out
20:49:38 <hub_cap> lets discuss when we are gonna revisit
20:49:40 <hub_cap> i want to tomorrow
20:49:41 <imsplitbit> I just meant it's way too early to make a decision
20:49:49 <hub_cap> cuz earthpiper is sitting twiddling his thumbs
20:49:51 <earthpiper> imsplitbit: not its not.
20:49:52 <imsplitbit> I would be disappointed if we ruled on this in just 50 minutes
20:49:58 <earthpiper> it's simple
20:50:03 <earthpiper> there is no other options really.
20:50:09 <earthpiper> For some DB's
20:50:09 <imsplitbit> earthpiper: it's simple to you because you see it your way
20:50:12 <hub_cap> earthpiper: its not simple
20:50:17 <hub_cap> +1 imsplitbit
20:50:23 <vipul> yea I think we finally just got some context behind all this..
20:50:25 <hub_cap> its simple if youve been thinking about it for 2 wks
20:50:25 <vipul> so need time
20:50:28 <vipul> to absorbe
20:50:33 <hub_cap> its not if you are vipul
20:50:35 <earthpiper> Indeed my bad
20:50:38 <imsplitbit> lol
20:50:41 <hub_cap> and a member of the core team w/o context
20:50:47 <imsplitbit> hub_cap: we have a crypto thing tomorrow
20:50:52 <imsplitbit> can we schedule around that?
20:51:07 <SlickNik> earthpiper: which is the first db service type that we're planning to try this with?
20:51:16 <hub_cap> hmm i dont have a crypto thing tomrrow imsplitbit ;)
20:51:23 <imsplitbit> some of us do
20:51:29 <hub_cap> SlickNik: caché
20:51:30 <vipul> tomorrow 2pst works for me
20:51:30 <grapex> Some of us have pre-existing lives
20:51:42 <earthpiper> SlickNik: I am working adding redis into trove.
20:51:45 <earthpiper> on*
20:51:45 <hub_cap> http://www.intersystems.com/cache/
20:51:47 <grapex> Or calendars that were arranged before we had a 24 hour deadline to argue what we wanted to do
20:51:50 <imsplitbit> I can't do 2 pst
20:51:57 <imsplitbit> ug
20:52:15 <grapex> I have to go home midway through tomorrow to look after mine and my neighbors dogs
20:52:17 <kevinconway> yeah, none of us CST guys are doing 2 pst
20:52:27 <imsplitbit> earthpiper: I'd like to discuss this with you face to face behind the gym after school :)
20:52:28 <grapex> So I'm not sure when I could get back on until about 1 pst
20:52:30 <kevinconway> thats like… X;XX o'clock
20:52:33 <hub_cap> ahh can u not do irc w/ the dogs grapex? understandable if not
20:52:34 <hub_cap> id like you to participate
20:52:41 <vipul> imsplitbit: lol
20:52:46 <hub_cap> i want hte core team to agree
20:52:47 <earthpiper> imsplitbit: you got bad knees dawg.
20:52:50 <hub_cap> or ill jus tmake a decision
20:53:01 <imsplitbit> earthpiper: and you can't run that fast :)
20:53:03 <hub_cap> so i want vipul SlickNik grapex hub_cap to decide
20:53:04 <grapex> hub_cap: I just don't want to pick a time when I'm in a meeting at Rax our in route
20:53:07 <vipul> 11pst?
20:53:08 <earthpiper> imsplitbit: I do like cake.
20:53:15 <hub_cap> grapex: lol OF COURSE!
20:53:15 <KennethWilke> punch and pie?
20:53:19 <imsplitbit> seriously tho earthpiper come see me tomorrow morning I would love to have more insight
20:53:20 <hub_cap> ok
20:53:23 <grapex> vipul: I could try to get in place by 11pst
20:53:24 * hub_cap bangs the gavel
20:53:26 <hub_cap> everyone shut up
20:53:31 * imsplitbit shuts up
20:53:32 <hub_cap> we need to pick a time
20:53:41 <KennethWilke> NOW
20:53:48 <earthpiper> KennethWilke: +1
20:53:48 <kevinconway> i'm available at 7:15 CST
20:53:49 <vipul> 11pst?
20:53:50 <SlickNik> 11pst works for me.
20:53:50 * TheRealBill chuckles
20:53:54 <kevinconway> long bus ride to san antonio
20:53:56 <vipul> dont' ask kevinconway
20:54:00 * grapex begins loudly speaking in tongues
20:54:12 <vipul> he comes up with crazy ass times
20:54:13 <hub_cap> ok how bout this
20:54:16 <imsplitbit> I'm ok with 11pst
20:54:18 <hub_cap> ill just decide what i want
20:54:23 <hub_cap> and be a dictator
20:54:35 <hub_cap> or we can be big boys and pick a time
20:54:39 <kevinconway> might want to pus hot 11:30 pst so we can get out of lunch and get back to a station
20:54:40 <imsplitbit> 11pst
20:54:53 <KennethWilke> tomorrow anytime 7-4cst
20:54:53 <imsplitbit> ok 1130
20:54:58 <grapex> It worked for agriculture in the Soviet Union... why not?
20:55:03 <hub_cap> 1130 pst / 130 pst?
20:55:07 <grapex> Sounds good
20:55:10 <hub_cap> done
20:55:11 <imsplitbit> 1:30 cst
20:55:11 <vipul> okie
20:55:16 <KennethWilke> k
20:55:16 <kevinconway> #agree
20:55:19 <SlickNik> okay, sounds good
20:55:23 <datsun180b> oh 1:30 CST makes more sense
20:55:23 <imsplitbit> #agree
20:55:27 <robertmyers> #agree
20:55:27 <imsplitbit> lol
20:55:38 <datsun180b> #agree
20:55:40 * KennethWilke puts on his armor and tight pants
20:55:42 <KennethWilke> battle to the death!
20:55:43 <imsplitbit> yeah two times in pst didn't make sense to me either datsun180b
20:55:49 <hub_cap> lol
20:55:55 <hub_cap> ok 5 min
20:56:02 <imsplitbit> KennethWilke: Texas is a "Stand your ground" state
20:56:03 <hub_cap> #topic open discussion
20:56:10 <imsplitbit> :)
20:56:13 <hub_cap> anyoen have anything?
20:56:14 <hub_cap> relevant
20:56:19 <imsplitbit> awe
20:56:23 <hub_cap> ya
20:56:29 <hub_cap> this hour is monitored
20:56:31 <SlickNik> hub_cap: so one thing that came up is the ability to tag / push to pypi
20:56:34 <hub_cap> as in, we need to be big boys
20:56:37 <kevinconway> i'd like to talk about users
20:56:40 <hub_cap> cuz all of openstack is watching
20:56:48 <hub_cap> kevinconway: do i need to reiterate?
20:56:50 <imsplitbit> good point
20:56:52 <hub_cap> cuz i can talk to your mgr
20:56:56 * hub_cap is serious
20:56:58 <grapex> hub_cap: Man they must be really bored!
20:57:26 <hub_cap> we can goof off all day long in #openstack-trove but this is a real meeting
20:57:36 <imsplitbit> yeah good point
20:57:37 <hub_cap> SlickNik: yes lets chat
20:57:39 <imsplitbit> anyone got anything
20:57:40 <KennethWilke> hmm, i wish i had something else to bring up, but the api is my main concern atm
20:57:44 <SlickNik> right now it's restricted to trove_ptl (which is a group that has only you)
20:57:47 <hub_cap> SlickNik: had a good point
20:57:52 <imsplitbit> oh
20:57:55 <hub_cap> so apparently only i can push to pypi?
20:58:15 <hub_cap> can we change that to anyoen in core SlickNik?
20:58:26 <SlickNik> Yeah, we can change this is we decide, but I wanted to run it by you guys first.
20:58:37 <hub_cap> yes +1
20:58:38 <SlickNik> Yeah, it's a change in the ci-infra scripts
20:58:40 <hub_cap> i trust core
20:59:03 <hub_cap> so i decree
20:59:03 <vipul> <3
20:59:05 <hub_cap> change it SlickNik
20:59:09 <SlickNik> grapex / vipul you guys okay with it?
20:59:19 <vipul> SlickNik yep
20:59:25 <grapex> SlickNik: Sounds good to me.
20:59:33 <hub_cap> ok done and done
20:59:41 <hub_cap> #action SlickNik to change the group for pypi upload
20:59:48 <hub_cap> :)
21:00:03 <SlickNik> thx hub_cap, was just about to action myself.
21:00:10 <SlickNik> That's all I had
21:00:13 <hub_cap> #endmeeting