20:02:15 <SlickNik> #startmeeting trove
20:02:16 <openstack> Meeting started Wed Sep  4 20:02:15 2013 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:19 <openstack> The meeting name has been set to 'trove'
20:02:22 <vipul> ;/
20:02:23 <robertmyers> o/
20:02:25 <vipul> ugh
20:02:29 <dmakogon_> what is the topic ?
20:02:31 <SlickNik> Hello all
20:02:33 <dmakogon_> hi
20:02:37 <imsplitbit> hola!
20:02:45 <SlickNik> Agenda is at https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_the_next_meeting
20:02:59 <kevinconway> 707
20:03:06 <SlickNik> Please update it if you have a topic you want to discuss.
20:03:11 <pdmars> o/
20:03:21 <dmakogon_> already
20:03:22 <arborism> o/
20:03:26 <SlickNik> #topic Update to Action items
20:03:39 <SlickNik> #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-08-28-20.02.html
20:03:54 <dmakogon_> isviridov: hi
20:04:04 <isviridov_> hi, everybody
20:04:10 <ashestakov> hi
20:04:11 <SlickNik> hub_cap to find out what happens w/ feature based reviews that land after FF
20:04:13 <imsplitbit> hai
20:04:15 <dukhlov_> hi
20:04:26 <imsplitbit> hub_cap is currently flying
20:04:34 <imsplitbit> in an aeroplane
20:04:44 <SlickNik> Yeah. He told me to cover for this one.
20:04:49 <dmakogon_> trove, guys, let's talk about it))
20:05:26 <SlickNik> So after FF the branch remains frozen until we cut our first release candidate (RC1)
20:05:41 <dmakogon_> yeah, that is how it works)
20:05:47 <SlickNik> Which should happen in about a week or so.
20:06:01 <dmakogon_> friday - H3
20:06:10 <dmakogon_> next friday RC
20:06:22 <SlickNik> Once we have RC1 cut, we open the branch again for icehouse submissions.
20:07:16 <SlickNik> any questions?
20:07:31 <SlickNik> okay, moving on...
20:07:31 <vipul> works for me
20:07:43 <SlickNik> SlickNik to leave current patch as is and investigate adding trove role to default devstack users in another patch.
20:08:06 <SlickNik> So that's what most of the other projects are doing.
20:08:17 <SlickNik> So I will be adding a follow up patch once the devstack patch lands.
20:08:33 <SlickNik> #link https://review.openstack.org/#/c/38169/
20:09:25 <SlickNik> datsun180b: you're up.
20:09:36 <SlickNik> trove-conductor update.
20:09:42 <datsun180b> Working on submitting my wip for trove-conductor now.
20:10:11 <datsun180b> It's not complete, but I have a daemon listening to a queue, and a guestagent that speaks to a queue
20:10:49 <SlickNik> Sweet. Looking forward to the review.
20:11:04 <dmakogon_> any updates about Conductor ?
20:11:06 <datsun180b> Well, it's not complete. I need to hand it off, as I'll be gone all of next week
20:11:20 <datsun180b> Hence a WIP review
20:11:21 <cp16net> hello sorry i'm late
20:11:22 <grapex> datsun180b: I'll try to pick that up (then I may pawn if off later though)
20:11:26 * grapex laughs sinisterly
20:11:49 <datsun180b> Fine by me, it'll be in good hands
20:11:50 <dmakogon_> any blocking stuff for Conductor ?
20:12:03 <SlickNik> heh, gotcha datsun180b
20:12:19 <datsun180b> dmakogon_: mostly configuration woes as i'm green to rabbit
20:12:41 <datsun180b> that's all for me, you'll see the reviews when i submit them
20:13:00 <grapex> With Rabbit it always seems like nothing works, until you get the last config tweaked perfectly
20:13:00 <SlickNik> Thanks datsun180b. Sounds good, let's move on…
20:13:19 <dmakogon_> datsun180b: ok
20:13:46 <isviridov_> datsun180b, any link to code?
20:13:55 <SlickNik> Okay, next: team needs to discuss and come up with a consistent JSON notation across API
20:14:04 <dmakogon_> datsun180b: could you paste any code or specification of Conductor ?
20:14:04 <kevinconway> datsun180b: code plox?
20:14:39 <juice> in the review guys
20:14:40 <SlickNik> dmakogon_ /isviridov: datsun180b's in the process of posting his WIP review.
20:14:46 <juice> you'll seeit all
20:15:02 <dmakogon_> ok
20:15:24 <SlickNik> So we still need to discuss having a consistent JSON notation.
20:15:34 <SlickNik> And haven't had a chance to do it so far.
20:15:40 <grapex> SlickNik: consistent JSON spec for the REST API?
20:15:45 <dmakogon_> about JSON: lets formalize notation and present it OpenStack community
20:15:55 <dmakogon_> present to
20:16:00 <kevinconway> i thought hub_cap already did that
20:16:25 <vipul> dmakogon_: i think that's been done in the past, but gone nowhere.. no harm in trying again i suppose
20:16:26 <SlickNik> grapex: yes. right now we have some variable using under_scores and others using camelCase...
20:16:43 <grapex> SlickNik: hub_cap made a wiki article on the next version of the API
20:16:46 <vipul> what was the decision?
20:16:49 <SlickNik> So the idea was we should formalize a consistent spec  for Trove.
20:16:51 <grapex> one feature of the wishlist was to have consistent JSON stuff
20:16:56 <dmakogon_> vipul: lets formalize JSON notation for trove and use it like standard
20:16:59 <SlickNik> At least for the next version of the API.
20:17:05 <isviridov_> I would suggest camelCase, as well as w3c uses it http://www.w3schools.com/json/
20:17:09 <kevinconway> i'm pretty sure hub_cap was for the underscored notation
20:17:20 <juice> it appears as the general rule is to follow python notation more so than any generic standard
20:17:30 <dmakogon_> vipul: agree with isviridov
20:17:32 <juice> this being the case, we should use underscores
20:18:08 <SlickNik> it seems like other openstack projects are divided and inconsistent regarding this as well.
20:18:13 <SlickNik> Which sucks.
20:18:14 <kevinconway> isviridov: w3schools is not w3
20:18:32 <vipul> #link https://wiki.openstack.org/wiki/Trove/NextAPI
20:18:41 <jrodom> i'd love to see general consensus across openstack programs ideally.
20:18:57 <isviridov_> kevinconway, but they really follows w3c
20:19:25 <juice> does one lend itself to dynamic binding more than the other?
20:19:38 <vipul> i don't believe so, since it's all dicts
20:19:51 <arborism> +1 on under_score. also, I agree w/ Jay's comments on the current JSON schema (which is not mentioned in that aforementioned wiki)
20:19:55 <juice> that is, if I were to run our api through several code generator or object binding frameworks which one works more consistently?
20:20:43 <SlickNik> I don't think we need to arrive at a consensus this very moment. I'd like to read up on it a bit more and revisit this when hub_cap is around as well.
20:20:49 <imsplitbit> +1 arborism
20:20:58 <imsplitbit> and +1 jay's comment
20:21:09 <vipul> what comment?
20:21:28 <vipul> oh recall a email thread...
20:21:45 <dmakogon_> what is the next topic ?
20:22:13 <dmakogon_> #topic MongoDB support
20:22:13 <SlickNik> We're still doing action items, dmakogon_
20:22:25 <vipul> #link http://lists.openstack.org/pipermail/openstack/2013-August/000850.html
20:22:32 <SlickNik> thanks vipul
20:22:43 <arborism> (thanks for the assist on that link vipul, you beat me ;) )
20:23:24 <SlickNik> okay let's move on to the next action item
20:23:34 <SlickNik> cp16net add the database model to the scheduled_task wiki
20:23:44 <cp16net> i've yet to do that...
20:24:00 <cp16net> i have it on my list
20:24:19 <SlickNik> okay, do you want to re-action it?
20:24:23 <cp16net> yes plz
20:25:11 <vipul> #action cp16net add the database model to the scheduled_task wiki
20:25:20 <cp16net> ty vipul
20:25:26 <SlickNik> thanks vipul
20:25:32 <SlickNik> #action team still needs to discuss and come up with a consistent JSON notation across API (hub_cap / grapex / vipul / SlickNik)
20:25:43 <SlickNik> Okay that's all for action items.
20:25:46 <SlickNik> Let's move on
20:25:49 <grapex> SlickNik: Ok, who has a coin to flip? :)
20:25:52 <cp16net> souds good
20:26:05 <vipul> grapex: likely going to come to that lol
20:26:05 <SlickNik> #topic Update on h3/rc1/icehouse
20:26:20 <datsun180b> grapex: http://www.random.org/coins/
20:26:25 <SlickNik> touched on that earlier.
20:26:29 <SlickNik> Nothing more to add.
20:26:48 <SlickNik> #topic MongoDB support https://blueprints.launchpad.net/trove/+spec/mongodb-support (needs approvement)
20:27:12 <SlickNik> dmakogon_: that's you I believe.
20:27:13 <vipul> woah MongoDB eh
20:27:30 <dmakogon_> trove should support MongoDB is popular enough
20:27:32 <SlickNik> or isviridov
20:27:43 <isviridov_> MongoDB is pretty common DB in NoSQL world, would like to see it in trove
20:28:05 <dmakogon_> and mongo has very interesting data storing schema
20:28:05 <isviridov_> need your approve
20:28:18 <arborism> isn't a mongodb blueprint jumping the gun considering the clustering api isn't finalized, region support isn't finalized, parameter groups aren't finalized, etc?
20:28:48 <vipul> I guess you could do a single instance mongo
20:28:51 <vipul> not sure how useful that will be
20:28:53 <demorris> no more than adding any other datastores
20:28:58 <isviridov_> arborism, you are right, it is one more reason to think about cluster-api better
20:29:14 <SlickNik> dmakogon_: I think we need some more info in the blueprint, about the idea and design.
20:29:20 <demorris> looking at support for it is a great set of data points to help shape all those features
20:29:40 <vipul> demorris: good point
20:29:56 <dmakogon_> SlickNik: we'll do that
20:29:58 <demorris> we run the risk of under delivering on those features if we don't include it in the discussions, so I seem them as able to run in parallel
20:30:02 <vipul> since Trove is approved to support no-sql, I don't see why this would be an issue
20:30:25 <vipul> just would be a single instance thing until clusters are fully baked
20:30:33 <dmakogon_> vupil: yes, why not ?
20:30:51 <dmakogon_> good point
20:31:12 <cweid> Rather than having * number of blueprints of what other sql or no sql services we want to support why don't we work on making it a trivial task to add in new db engines..
20:31:36 <dmakogon_> for now we could tweak trove for provisioning single instance of anything
20:31:48 <ashestakov> cweid: +1
20:31:55 <vipul> cweid: I think some of those things only get easier when you actually attempt to add another datastore
20:32:06 <cweid> Correct
20:32:11 <grapex> cweid: http://www.codinghorror.com/blog/2013/07/rule-of-three.html
20:32:11 <cweid> but right now we have 3 pending.
20:32:22 <SlickNik> dmakogon_: I'm not sure what you mean by "tweak" trove. Trove already supports multiple managers for the guest agent.
20:32:24 <dmakogon_> after cluster api will be finished, we'll try to do specification for mongo cluster
20:32:27 <arborism> cweid/vipul: agreed, but the existing clustering api mail thread is already discussing 3+ datastores
20:32:59 <arborism> i was just pointing out that some final consensus is needed there first, before a super-detailed mongodb spec is written
20:33:24 <grapex> cweid: Well I think for now we do blue prints on new data stores, and as they come in, things in Trove should naturally become easier to reuse and more flexible (unless we screw up)
20:33:33 <vipul> Sure, it's not just about clustering, i think there is room for improvement in guest agent and taskmanger for example..
20:33:46 <dmakogon_> grapex: +1
20:33:53 <isviridov_> arborism, with analizing other dbs we are getting cleare vision of cluster api also
20:34:00 <arborism> correct, yes.
20:34:10 <dmakogon_> isviridov +1
20:34:27 <isviridov_> there is demand of HA cluster, not just set of engines
20:34:41 <SlickNik> vipul: I agree with you. I'd like to take those improvements to trove, but as part of being able to support "n" implementations, not specifically MongoDB, for example...
20:35:31 <vipul> SlickNik: sure, but we have no other implementation of another engine happening in Public Trove.. (at least i have not seen much code)
20:35:50 <vipul> I know we're talking about implementing Redis, and we are doing Vertica, etc..
20:36:08 <vipul> but there isn't much refactoring, pluggability work going on currently to support those
20:36:44 <kevinconway> couldn't we just make db engines some kind of extension that we plug in?
20:36:53 <arborism> since it seems like there's quite a bit of interest in this, i'd ask that people who haven't read that mail thread do so, because it's trying to address all of the topics being brought up, at least from a generic api perspective. I'd love to see comments about guest/taskmanager refactorings as well.
20:36:57 <cp16net> vipul: yeah i agree and that leads to me to thinkin not much *needs* to change now
20:37:13 <cweid> vipul: here is Trove sertup to support Redis. https://github.com/cweidenkeller/trove
20:37:15 <demorris> that work is already in progress, types/version blueprint is a step in that direction
20:37:24 <grapex> vipul: As people do new db types, I think we should gate them on making sure the code is refactored enough that they don't stick out like a sore thumb or create issues, naturally putting pressure on keeping the code clean and making it more pluggable as the implementation count increases.
20:37:42 <kevinconway> arborism: link to thread?
20:37:44 <vipul> cweid: thanks
20:37:45 <SlickNik> I'm totally good with this, but I'd like to see more details on what  changes are needed added to the blueprint. Things like "We need to support X for better multi-engine support in trove", and not necessarily "We need to support Y because MongoDB"
20:37:54 <vipul> grapex: +1
20:38:40 <SlickNik> yup agree with grapex as well.
20:38:45 <vipul> SlickNik: agreed, let's use the Mongo BP as a place to do this
20:38:58 <arborism> kevinconway: http://lists.openstack.org/pipermail/openstack/2013-August/000719.html
20:39:18 <demorris> SlickNik: agree, this is step one to that - https://wiki.openstack.org/wiki/Trove/trove-versions-types
20:39:18 <arborism> specifically the gist I provided, talking about how to generically support cassandra + mongo + mysql + regions
20:39:29 <vipul> cweid, cp16net: lookign at https://github.com/cweidenkeller/trove/blob/master/trove/guestagent/manager/redis.py -- i see a lot of duplication between that and mysql.py
20:39:42 <vipul> seems like that would be a perfect opportunity to create some sort of an interface..
20:39:44 <demorris> right now sure you can make whatever run in Trove, but you can't actually run multiple DB engines and types on the same install
20:40:40 <grapex> demorris: Maybe we do need to do some bare minimum work to make running multiple DB engines (aka service_types) at once possible- and just make which ones are enabled configurable. Then we should all agree to be a bit lax with these new db types-
20:40:57 <arborism> +1 grapex
20:41:16 <isviridov_> grapex, +1
20:41:38 <cp16net> i agree we need to be able to (dis)(en)able service types
20:41:47 <SlickNik> agreed grapex.
20:41:48 <grapex> and let code for them get checked in without being 100% done. I don't like that, but there will need to be changes to make Trove more flexible while the Mongo and Redis guys add there work, so we'll need to gate a bit less than usual (i.e. features for these types won't have to work 100% before a commit)
20:42:39 <vipul> sure, grapex.  I'd welcome changes that really make it pluggable
20:42:42 * grapex wishes he'd spelled "there" "their"
20:42:58 <datsun180b> grapex: forty lashes
20:43:41 <vipul> to be continued?
20:43:59 <grapex> vipul: So the issue is, will these changes be led by the veterans or the people making new DB types? I think the pressures of what everyone's boss wants them to do will mean the new DB implementers may need to make it pluggable, but the friction is they may not always know the greatest way to do that since they're a bit new to the project.
20:44:17 <SlickNik> Looking like one to me.
20:45:07 <SlickNik> So with the bp in question though; I'd like to see a bit more definition in what this entails and how much of the trove-core code needs to change for it.
20:45:09 <vipul> grapex: sure, it could be the vets.. I doubt we'd be abel to refactor everythign necessary for anothre service type
20:45:10 <grapex> Plus, we don't really always know what it would take to add Redis or Mongo since we're not adding them ourselves, so I guess my point is we should allow some limited Redis and Mongo code to get in early on.
20:45:36 <grapex> And lax our standards to jump start the conversation- just for a bit, and just so long as nothing that's working today breaks.
20:45:57 <vipul> grapex: i'm cool with that
20:46:22 <SlickNik> So I'd love for it to drive other changes in trove-core to make it more pluggable.
20:46:29 <vipul> it's gonna have to be a combination of us going in there and refactoring, and also code review suggestions
20:46:47 <grapex> vipul: I think so.
20:47:29 <vipul> time check :)
20:47:32 <SlickNik> So what I'm hearing is approve the bp for an initial stab at adding mongo
20:47:36 <SlickNik> Whoops.
20:47:42 <dmakogon_> i thinks we've done with Mongo BP
20:48:03 <SlickNik> okay move on for now...
20:48:11 <SlickNik> to be continued.
20:48:28 <SlickNik> #topic virgo based guest-agent (https://github.com/racker/virgo, https://github.com/racker/virgo-base)
20:48:47 <dmakogon_> who want to tell us about this client >
20:48:49 <dmakogon_> ?
20:48:57 <SlickNik> Who added this to the agenda?
20:49:23 <vipul> skip
20:49:28 <SlickNik> hmm…okay.
20:49:30 <SlickNik> moving on.
20:49:33 <isviridov_> was in open discussion
20:49:38 <demorris> why not discuss it
20:49:49 <vipul> who knows about it
20:50:05 <SlickNik> demorris: who's the right person to discuss it?
20:50:06 <vipul> i heard it for the first time yesterday
20:50:09 <dmakogon_> anyone have something to tell? discuss ?
20:50:10 <ashestakov> i tried to research virgo today, where is server part for it?
20:50:31 <vipul> I think it would be just the agent
20:50:36 <cp16net> its just an agent
20:50:38 <isviridov_> it was mentioned as on of possible implementation for guest-agent, any info about it?
20:50:42 <ashestakov> to where it reporting?
20:50:42 <grapex> Virgo is the guest agent used by Rackspace monitoring
20:51:15 <demorris> it is a lightweight C-based agent with extensible Lua scripting for agent logic
20:51:16 <ashestakov> can it receive rpc calls?
20:51:22 <grapex> If whoever raised it isn't here to talk about it I think we should move on- its basically an agent framework of sorts written on top of luvit, which is NodeJS for Lua
20:51:37 <SlickNik> I think this discussion might be best suited for #openstack-trove after the meeting (since it's more of a knowledge sharing one)
20:51:44 <isviridov_> let us move  on
20:51:57 <SlickNik> #topic trove refactoring: guestagent main issues (dmakogon)
20:52:11 <dmakogon_> my point
20:52:18 <dmakogon_> GA issues
20:52:19 <dmakogon_> Weaken trove.guestagent.manager.mysql & .mysql_service dependency on trove.instance.models -- actually only small set of constants and one simple persistent model is required, not the whole bunch of code
20:52:31 <dmakogon_> Same with trove.guestagent.backup vs trove.backup.models
20:52:46 <dmakogon_> trove.guestagent.strategies should not use trove.common.remote. The latter pulls lots of stuff but only trivial one-line call is actually needed
20:53:08 <dmakogon_> Check trove.guestagent.manager.mysql.mysql_service dependency on trove.extensions.mysql.models (may be not so easy/important)
20:53:10 <vipul> dmakogon_: nice! with conductor, the models dependencies are gone
20:53:20 <dmakogon_> vipul: thanks
20:53:41 <SlickNik> dmakogon_: There's also another bp out to separate the guest agent into it's own repo / package to decouple it further.
20:53:47 <SlickNik> So this is all goodness.
20:54:07 <SlickNik> And if you opened a bug and fixed some of these issues, I'm sure no-one here would object :)
20:54:18 <vipul> please add these to that bp, just to track them
20:54:25 <dmakogon_> SlickNick: we don't wont to extract GA to separate repo
20:55:01 <dmakogon_> SlickNik: we want to break dependencies
20:55:14 <dmakogon_> this is the main goal
20:55:20 <grapex> dmakogon_: If it got its own repo it would become skinny quick.
20:55:22 <vipul> dmakogon_: at some point, for packaging pusposes we should also consider moving it to a spearate repo
20:55:26 <grapex> I know the two goals can be made seperate
20:55:33 <grapex> but one would help the other.
20:55:40 <vipul> grapex: +1
20:55:41 <SlickNik> I'm totally fine with tackling the two separately.
20:55:53 <SlickNik> But they're related.
20:55:58 <dmakogon_> vipul: i thinks, not
20:56:26 <dmakogon_> we should break deps and keep project together
20:56:30 <isviridov_> what about common code for both projects?
20:56:37 <vipul> oslo?
20:56:43 <robertmyers> dmakogon_: that is not allowed
20:56:55 <isviridov_> constants, so on
20:56:55 <robertmyers> only one setup.py per git repo
20:56:56 <cp16net> there is common agent code in oslo
20:56:56 <grapex> dmakogon_: I would like fewer repos myself, but alas, tis not the way of OpenStack.
20:57:20 <vipul> ok we need to revist this i think
20:57:26 <SlickNik> this seems like a tangent.
20:57:52 <vipul> 3 mins..
20:57:57 <kevinconway> we could put each daemon in it's own repo!
20:57:58 <SlickNik> Let's revisit this and keep going
20:58:12 <isviridov_> seems better to keep it in one repo, or api should be defined
20:58:14 <SlickNik> #topic versions / service_types
20:58:28 <ashestakov> its mine
20:58:38 <ashestakov> lets see this one again https://gist.github.com/andreyshestakov/b1f1b06fd4aef18011ea
20:58:40 <SlickNik> take it away, ashestakov
20:58:43 <isviridov_> also affects cluster api
20:59:28 <vipul> ashestakov: why separate the service_type_id and verstion_id?
20:59:35 <vipul> shoudln't they be grouped (on instance create)
20:59:46 <ashestakov> vipul: we disscussed this on previos meeting
21:00:22 <vipul> ok missed that then
21:00:25 <ashestakov> version_id is optional, you should specify it only you have multiple active versions
21:00:39 <ashestakov> there another issue
21:00:40 <vipul> tehy could still be grouped, since they are related things
21:01:17 <ashestakov> in that spec, once we eliminated service_type as it is now (eg, mysql and percona), we should add same parameter
21:01:23 <grapex> vipul: I agree, it optimizes the case with no multiple versions but it less organized if you do have them.
21:02:11 <vipul> ashestakov: how about talking about it in openstack-trove later
21:02:26 <ashestakov> vipul: after this meeting?
21:02:55 <vipul> soem folks might be leaving
21:03:00 <SlickNik> yup, let's talk about it immediately after this meeting.
21:03:07 <vipul> ok we can do that too
21:03:15 <kevinconway> if it's a meeting time you should probably reschedule it for next time as well
21:03:24 <SlickNik> Or we can pick another time if folks are leaving.
21:03:31 <kevinconway> time = item
21:03:39 <SlickNik> Let's move on for now
21:03:55 <SlickNik> #topic guest_agent service registry (dict_opt vs single opt)
21:04:02 <SlickNik> who's got this one?
21:04:08 <grapex> So I'll comment
21:04:18 <vipul> please do
21:04:26 <grapex> Is this about the guest config file having both a dictionary of managers, and a key to which of those managers to use?
21:04:37 <vipul> yes
21:05:02 <grapex> I don't get the utility of it, as it appears the dictionary isn't used out of the bin script
21:05:05 <grapex> Maybe I missed something?
21:05:25 <vipul> I think the idea is if we want to suppot a single package of guest agent that support >1 service types
21:05:32 <vipul> how do we dynamically load the 'manager'
21:05:42 <vipul> based on the service type of the instance
21:05:54 <grapex> I guess my issue is the manager could be as easily loaded by specifying the class name
21:06:05 <vipul> as a single conf entry?
21:06:08 <grapex> Yes
21:06:10 <vipul> yes you could do that..
21:06:17 <vipul> means you have different confs for different service types
21:06:25 <vipul> i guess there is a bit my dynamicism if you go with dict
21:06:33 <vipul> because the same conf can be resued
21:06:37 <SnowDust> +1 vipul on that
21:07:01 <isviridov_> +1 vipul
21:07:02 <grapex> How? To change which manager is loaded, you have to still change the conf
21:07:04 <dmakogon_> vipul: i thinks we could do dynamic module deliveries
21:07:17 <vipul> the conf would contain all possible managers
21:07:25 <dmakogon_> vipul: yes
21:07:32 <vipul> servie_type (hopefully in the future) is something that will be passed into guest_info
21:07:35 <dmakogon_> than we do dymamic load
21:07:43 <grapex> Ah
21:07:45 <SlickNik> grapex: I think the idea would be to have all managers in the conf, and the pick the manager based on the service_type (in the rpc call?)
21:07:56 <ashestakov> vipul: backup/restore strategies still using mysql impl
21:07:58 <vipul> rpc call would be too late
21:08:01 <grapex> SlickNik: Ok- I thought that maybe that was the plan.
21:08:38 <vipul> yea, we wnat to gradually configure the backup / restore strategies as well
21:08:49 <vipul> this is step #1 to getting the right manager loaded
21:08:54 <grapex> Ok, I feel it could be YAGNI but I'm ok if we're all on board with making use of the dictionary very soon
21:09:05 <dmakogon_> about automated backups
21:09:23 <dmakogon_> Automated backup design: 1. Define limits for backups per tenant. 2. Define storing strategy. 3. Define timing strategy. 4. Define cluster backup strategy than 1-3 for cluster
21:09:29 <SlickNik> Yeah, this is the same thing with backup / restore.
21:10:06 <dmakogon_> what do you say ?
21:10:09 <SlickNik> dmakogon_: You might want to talk to cp16net about that as feedback for him.
21:10:26 <SlickNik> I'm fine with the dict_opt
21:10:26 <dmakogon_> SlickNic: ok
21:10:45 <SlickNik> anything else to add, vipul?
21:10:54 <vipul> no i'm good...
21:10:55 <dmakogon_> about registry, cool with dict
21:11:03 <SlickNik> Okay, #topic open discussion
21:11:05 <kevinconway> datsun180b: Conductor code?
21:11:13 <SlickNik> #topic Open Discussion
21:11:14 <juice> Just one closing note - I did a bit of JSON API comparison - of 13 sites: 8 use _ (underscore); 3 use camelCase; 1 uses - (dash); and the last one was all lowercase
21:11:35 <vipul> juice: nice!
21:11:42 <datsun180b> kevinconway: pay attention, both reviews are up
21:12:01 <vipul> we shoudl look at things like jackson too, see if they expect a certain type
21:12:09 <vipul> my guess is probably not
21:12:14 <SlickNik> Good info juice.  I'm leaning towards _ too. (mostly because it's what we already use in the majority of situations)
21:12:24 <juice> jackson you can specify what ever field name you like
21:12:49 <juice> @XMLElement("my_dogs_name") or something like that
21:12:53 <SlickNik> Okay, I think we're good with the meeting. Let's take further discussion to #openstack-trove
21:13:04 <SlickNik> Thanks all, and sorry for the OT.
21:13:09 <SlickNik> #endmeeting