20:00:08 <hub_cap> #startmeeting trove
20:00:09 <openstack> Meeting started Wed Aug 14 20:00:08 2013 UTC and is due to finish in 60 minutes.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:12 <openstack> The meeting name has been set to 'trove'
20:00:22 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
20:00:31 <grapex> o/
20:00:36 <vipul> hub_cap: refresh if you haven't
20:00:44 <kevinconway> \\o//
20:00:55 <djohnstone> o/
20:00:58 <vipul> woah kevinconway
20:01:03 <hub_cap> ok there was only 1 action item called DOC DOC DOC
20:01:12 <hub_cap> kevinconway: are you doc oc?
20:01:15 <imsplitbit> o/
20:01:39 <cp16net> o^/
20:01:39 <pdmars> o/
20:01:40 <hub_cap> i think we are still being kinda lax on the doc standards we proposed
20:01:47 <SlickNik> I haven't seen that many more docstrings.
20:01:54 <amytron> o/
20:01:58 <hub_cap> but thats ok, we will get better at screaming at people in gerrit
20:02:02 <grapex> SlickNik: Is there a way to get Gerrit to enforce that?
20:02:05 <hub_cap> ya SlickNik ive approved reviews w/o even looking...
20:02:06 <grapex> I'll try to keep that in mind
20:02:13 <grapex> Honestly I forgot all about it... :(
20:02:14 <SlickNik> grapex: not that I know of.
20:02:16 <hub_cap> no grapex.. gerrit enfoces nothing...
20:02:29 <hub_cap> wed have to write someting custom to get zuul / jenkins to enfoce it
20:02:29 <grapex> That's the problem with Gerrit, the lack of sentient thought
20:02:29 <SlickNik> Yeah, I'm going to start pushing back on code reviews because of it.
20:02:36 <hub_cap> ya we should SlickNik
20:02:43 <hub_cap> ok so lets skip to the next item
20:02:45 <kevinconway> hub_cap: pylint has an option to error if missing a doctstring. it would be retroactive for all code though
20:02:47 <juice> o/
20:02:47 * KennethWilke takes note... add sentience to gerrit
20:02:56 <hub_cap> kevinconway ;)
20:03:03 <grapex> kevinconway: I wonder if Zul has some trick where pylint would just apply to the diff
20:03:28 <hub_cap> lets not worry about it. Core team... do our job ;)
20:03:31 <hub_cap> we will enforce it manually
20:03:35 <datsun180b> that's a great way to lock away old code in a vault forever to keep from risking having to add docstrings
20:03:42 <hub_cap> HAH
20:03:46 <hub_cap> #topic clustering api update
20:03:48 <hub_cap> imsplitbit: tag
20:03:58 <grapex> datsun180b: Then you have to add docstrings explaining why it's broken :)
20:04:07 <imsplitbit> ok
20:04:17 <imsplitbit> #link https://review.openstack.org/#/c/41993/
20:04:17 <imsplitbit> #link https://review.openstack.org/#/c/41995/
20:04:24 <imsplitbit> clustertypes api
20:04:28 <datsun180b> i say turn on the firehose and deal with the mess once instead of incrementally forever
20:04:31 <imsplitbit> and support for it in troveclient
20:04:40 <imsplitbit> please review
20:04:40 <vipul> woah nice.. didn't see these before
20:04:48 <imsplitbit> cause they just went up :)
20:04:56 <SlickNik> they appeared recently :)
20:05:03 <cweid> imsplitbit: do they have docstrings?
20:05:05 <cweid> =)
20:05:08 <imsplitbit> of course
20:05:20 <imsplitbit> I'll be working on the cluster api tonight
20:05:25 <imsplitbit> hopefully it won't take as long
20:05:33 <imsplitbit> I think I got the api stuff figured out
20:05:48 <imsplitbit> this was my first foray into the world of the api
20:05:54 <vipul> you survived
20:06:06 <imsplitbit> yep
20:06:09 <vipul> so are you going to submit the cluster api without impl?
20:06:15 <imsplitbit> yes
20:06:18 <vipul> is it cool to return no-op?
20:06:22 <imsplitbit> then I'll submit an impl
20:06:35 <hub_cap> woo we got our first reviews to not make the Havana release ;)
20:06:35 <hub_cap> but srsly good work imsplitbit
20:06:35 * hub_cap thinks u might need to abandon those to put them on a feature branch tho
20:06:35 <hub_cap> can you talk to openstack-infra to see if there is a way to move a review to a feature branch in gerrit via git review?
20:06:35 <hub_cap> #action imsplitbit to move his clustering reviews to a feature branch
20:06:39 <hub_cap> #link https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches
20:06:46 <imsplitbit> I think if I submit the cluster api with an impl you guys will hate me for submitting a several thousand line review
20:06:49 <imsplitbit> :)
20:06:56 <vipul> yup, agreed
20:07:26 <imsplitbit> thats all I got to say about that
20:07:27 <hub_cap> ya hes gonna push them to a feature branch and the 2nd review will cover that part
20:07:34 <hub_cap> cool great work
20:07:43 <hub_cap> MANY people are interested in clustering
20:07:43 <SlickNik> Agreed on the feature branch piece. (And the non-havana part too)
20:08:13 <hub_cap> ok so moving on
20:08:13 <hub_cap> #topic h3 update
20:08:15 <hub_cap> #link https://launchpad.net/trove/+milestone/havana-3
20:08:30 <hub_cap> we are looking good for h3 still
20:08:44 <hub_cap> only 1 bug thats not fixed
20:08:55 <hub_cap> and 0 bps that are _not_ in progress
20:09:05 <vipul> nice
20:09:13 <SlickNik> https://bugs.launchpad.net/trove/+bug/1199507 is not assigned to anyone yet.
20:09:28 <hub_cap> and for some reason its only a "medium"
20:09:30 <hub_cap> interesting
20:09:30 <SlickNik> Looks fairly straightforward though.
20:09:33 <vipul> what happens between H-3 (9/5) and summit
20:09:48 <hub_cap> vipul: we go on break
20:09:53 <vipul> woohoo!
20:09:54 <hub_cap> ever seen summer school?
20:09:57 <SlickNik> holiday!
20:10:00 <juice> hub_cap there says there is a review for it
20:10:01 <hub_cap> we are the guy whos zipper got stuck
20:10:12 <juice> 507 that is and you are the one who worked on it
20:10:23 <hub_cap> juice: thats VERRRRY odd
20:10:41 <vipul> hub_cap: why is this a bug though
20:10:50 <vipul> i did'nt think trove supported reset_password
20:10:51 <hub_cap> #action hub_cap to review https://bugs.launchpad.net/trove/+bug/1199507
20:10:55 <vipul> you just enable root multiple times
20:11:08 <hub_cap> wait this should be in troveclient
20:11:11 <SlickNik> vipul, I think it should be a cli bug
20:11:13 <SlickNik> yup
20:11:13 <hub_cap> Available actions for 'instance' cmd:
20:11:16 <hub_cap> reset_password Reset the root user Password
20:11:34 <SlickNik> moved to python-troveclient
20:11:38 <hub_cap> seems like its missplaced
20:11:40 <hub_cap> thx SlickNik
20:11:43 <hub_cap> #undo
20:11:44 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x2544910>
20:11:54 <SlickNik> sounds good, carry on
20:11:56 <hub_cap> def
20:11:58 <hub_cap> moving on
20:12:14 <hub_cap> ok feature freeze info is gonna be fun
20:12:20 <hub_cap> #topic feature freeze
20:12:28 <hub_cap> #link https://wiki.openstack.org/wiki/FeatureProposalFreeze
20:12:34 <hub_cap> #link https://wiki.openstack.org/wiki/FeatureFreeze
20:12:46 <hub_cap> we have a tentative feature freeze for Sep4, just liek the other projects
20:13:06 <hub_cap> the feature proposal freeze should happen sooner, but no date is set
20:13:09 <hub_cap> this is a dry run
20:13:14 <hub_cap> we are not 100% solid on this
20:13:20 <hub_cap> we can have stuff slip in
20:13:33 <hub_cap> for instance, heat support _has_ to get in, and it wont make the FPF
20:13:40 <hub_cap> so real quick
20:13:53 <hub_cap> FPF means if its not on review.openstack.org, its not going in h3
20:14:04 <hub_cap> FF means if its not a bug, its not going in 2013.1
20:14:15 <hub_cap> FF also means h3 gets cut
20:14:28 <vipul> so we are officially in FPF now
20:14:35 <hub_cap> and then we go into the cycle of RC's to determine our "bug free (lol)" 2013.1 releas
20:14:49 <hub_cap> we havent set the date vipul... so we are in FPF limbo
20:14:56 <hub_cap> i still want to see those items in h3 impl'd
20:15:04 <hub_cap> so i think we are going to be lax on FPF this go-round
20:15:10 <SlickNik> it says one or two weeks ahead of FF
20:15:27 <hub_cap> but yes, if we were 100% obeying, sometime next wk would be FPF
20:15:47 <vipul> kk
20:15:49 <hub_cap> meaning if its not already proposed on gerrit, its not going into h3
20:15:53 <hub_cap> unless its a bug of course
20:16:16 <hub_cap> then we hit FF and NOTHING thats not a bug goes in till we get 2013.1 cut
20:16:38 <hub_cap> so when i joked about imsplitbit's feature eariler its because he would be a good candidate for the FF
20:16:44 <hub_cap> and we can leave it unmerged
20:16:57 <vipul> man so nothing until Nov.
20:16:57 <hub_cap> #action hub_cap to find out what happens w/ reviews that land after FF
20:17:02 <hub_cap> #undo
20:17:03 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x24c5310>
20:17:09 <hub_cap> #action hub_cap to find out what happens w/ feature based reviews that land after FF
20:17:21 <hub_cap> does that make sense to everyone?
20:17:24 <hub_cap> any questions?
20:17:33 <SlickNik> yes, that makes sense.
20:17:33 <hub_cap> im giong to be strict on some things, but not everything
20:17:36 <KennethWilke> sounds good
20:17:50 <amytron> makes sense
20:18:08 <hub_cap> cool. if no one has any Qs then we can move on
20:18:09 <kevinconway> the freeze sounds… ice
20:18:16 <kevinconway> *nice
20:18:19 <hub_cap> if you think you are wrongly FF'd then plz talk to me 1x1
20:18:22 <hub_cap> its ice too kevinconway
20:18:27 <amytron> :)
20:18:57 <key2> what about teally big features like Cassandra support?
20:18:58 <hub_cap> id like to not affect any of the teams this go-round if possible. i knwo we are all trying to deal w/ a real product currently
20:19:06 <key2> *really
20:19:20 <hub_cap> key2: id LOVE to see cassandra support ;) but not in Havana
20:19:30 <hub_cap> we are way to far along for cassandra now
20:19:55 <hub_cap> but if you are going to work on it, then propose the BP and lets get it done for icehouse
20:20:07 * hub_cap thinks itll depend greatly on the clustering api too which is still in the works
20:20:11 <vipul> kinda sucks it's 2 months!
20:20:19 <hub_cap> well its not vipul
20:20:19 <vipul> from H3 -> 2013.1
20:20:24 <key2> it would be interesting
20:20:26 <hub_cap> once we cut a 2013.1 release
20:20:35 <hub_cap> key2: hell ya it will. /me wants some cassandra!
20:20:44 <key2> ))
20:20:49 <hub_cap> lisp?
20:21:00 <hub_cap> if we deem there are no critical bugs in the code we can decide to cut 2013.1 vipul
20:21:02 <key2> smile :)
20:21:05 <hub_cap> we can cut early
20:21:10 <hub_cap> key2 :P
20:21:12 <vipul> hub_cap: oh ok.. then that's coo
20:21:20 * hub_cap assumes vipul ;)
20:21:30 <hub_cap> i doubt we have 2 mo of bugs to work out
20:21:45 <SlickNik> we can figure that out once we get closer to that date.
20:22:03 <hub_cap> unless i push puro crap up for heat support
20:22:08 <hub_cap> exactly SlickNik
20:22:14 <hub_cap> moving on?
20:22:19 <vipul> yessir
20:22:26 <SlickNik> sounds good
20:22:34 <hub_cap> #topic redstack vs devstack users
20:22:40 <hub_cap> so real quick let me splain
20:22:52 <hub_cap> we have a set of users (radmin for sure) that we use in redstack
20:23:43 <hub_cap> this is different from the ones that devstack uses
20:23:43 <hub_cap> so when i ./redstack rd-client instance create
20:23:43 <hub_cap> then
20:23:43 <hub_cap> . ~/devstack/openrc && nova list
20:23:43 <hub_cap> i see nothing
20:23:43 <hub_cap> because they are on different tenants
20:23:47 <hub_cap> robertmyers: has mentioned issues as well w/ horizon integration wrt our users vs devstack users
20:23:58 <hub_cap> so im going to rip out the extra users and use the devstack users in redstack
20:24:07 <hub_cap> and hopefully including the tests (on pass one)
20:24:15 <datsun180b> our tests for the most part should be selecting different users for tests via the Requirements filter, so changing the list of users ideally shouldn't hurt us so long as the set still spans all the different kinds of users we need
20:24:23 <datsun180b> and our tests aren't trying to call the users by name deliberately
20:24:23 <hub_cap> if the tests end up failing miserably im going to push a WIP review up for someone else to finish
20:24:34 <grapex> hub_cap: Sounds good enough
20:24:42 <vipul> isn't there a requirement to have a role added?
20:24:54 <vipul> or will existing users just work with trove
20:25:00 <hub_cap> yup thats the hope datsun180b that it doesnt fail miserably
20:25:01 <hub_cap> i think boss/chunk will still be created/used for specific tests
20:25:03 <hub_cap> this is for the main user thats run thru
20:25:15 <hub_cap> vipul: is there a req?
20:25:31 <datsun180b> hub_cap: i said "i agree" but i took two lines to do it
20:25:33 <vipul> thought so.. i could be wrong
20:25:33 <SlickNik> yes, vipul is right.
20:25:59 <SlickNik> You'd have to add the trove role to the existing devstack users, I think
20:26:01 <hub_cap> https://gist.github.com/hub-cap/6235210
20:26:19 <hub_cap> thats the list of roles i have currently in my devstack+redstack install
20:26:47 <datsun180b> i think we need at least one, maybe two admin users, and at least two non-admin users
20:26:59 <hub_cap> datsun180b: we can let redstack deal w/ those
20:27:02 <SlickNik> It might work for admin, but wouldn't work for guest.
20:27:08 <hub_cap> but those arent the ones that ./redstack rd-client uses
20:27:27 <hub_cap> the primary reasoning was to align the cli calls between us and devstack
20:27:35 <hub_cap> when you source openrc
20:27:39 <grapex> hub_cap: So really, it's just getting rid of radmin and replacing it in the tests with the demo user?
20:27:43 <vipul> hub_cap: the bug you linked is something different though
20:27:45 <SlickNik> We can just add the role to the devstack users though. They will _always_ exist.
20:27:53 <hub_cap> it is, i havent created a bug for this yet vipul
20:27:58 <vipul> ah ok
20:27:59 <hub_cap> this is another thing that needs knocking out tho
20:28:08 <hub_cap> you can do a heat stack-list and its different from ./redstack rd-client
20:28:19 <hub_cap> so when i get to testing (and when robertmyers is testing horizon) its teh suck
20:28:35 <hub_cap> im not sure exactly waht it entails grapex but i think the answer is yes
20:28:39 <vipul> as part of our devstack patch.. SlickNik do we assign the role ot any existing?
20:28:49 <grapex> Yeah- keep in mind the tests round-robin the users they select; it's kind of a coincidence rd-client uses the same user used by most of the test
20:28:50 <robertmyers> yes, it is a little silly to have our own special users
20:29:03 <grapex> I don't think we need to fix this yet, but it'd be kind of cool if rd-client picked the user-
20:29:11 <SlickNik> vipul: only the ones we create (not the default devstack ones)
20:29:16 <grapex> but I agree that the devstack created demo user should be used for the tests.
20:29:48 <SlickNik> vipul: same behavior in redstack
20:29:58 <vipul> SlickNik: ok, cool..
20:30:13 <vipul> so now that we'll be official devstack.. safe to change existing users i'd imagine
20:30:23 <hub_cap> yes
20:30:34 <hub_cap> for now ill just mirror what devstack is using
20:30:38 <hub_cap> frankly, all the projects use demo
20:30:47 <hub_cap> thats what the openrc sets
20:30:51 <cp16net> yes
20:30:55 <vipul> that works
20:31:00 <hub_cap> :)
20:31:01 <grapex> hub_cap: +1
20:31:10 <SlickNik> I like the idea of removing radmin, and adding the "trove" role to admin and demo.
20:31:12 <hub_cap> we can let SlickNik figure out the nuances w/ his devstack review ;)
20:31:24 <SlickNik> that I can do. :)
20:31:34 <hub_cap> cool SlickNik maybe just do that in the devstack review now
20:31:41 <hub_cap> so its not merged w/ radmin
20:31:48 <hub_cap> good everyone?
20:31:59 <SlickNik> sounds good.
20:32:28 <hub_cap> #topic blueprints
20:32:30 <SlickNik> #action SlickNik update devstack review to add role to default devstack users.
20:32:40 <hub_cap> #link https://blueprints.launchpad.net/trove/+spec/pluggable-db-implementations
20:32:44 <yogesh_> This is on further abstraction of guestagent for implementing specific database managers...
20:32:46 <hub_cap> yogesh_: around?
20:32:49 <hub_cap> cool
20:32:51 <yogesh_> yes..
20:32:52 <hub_cap> can u explain a bit?
20:33:01 <hub_cap> i guess answer this
20:33:05 <hub_cap> how do we not do that today?
20:33:28 <hub_cap> today we have a generic api + XXX.py impl. coudl be redis, could be mysql, could be cassandra ;)
20:33:32 <yogesh_> the idea is to separate the manager implementations from trove
20:33:34 <hub_cap> how does that not work
20:33:40 <vipul> If i read correctly, it seems we need the ability to load a different package?
20:33:42 <hub_cap> we have that already yogesh_
20:33:49 <SlickNik> hub_cap: You need to be part of a registry today.
20:34:11 <yogesh_> we can not plug any db implementation of the manager in...
20:34:42 <yogesh_> if the design goes like, having the contracts sty in trove..
20:34:49 <hub_cap> SlickNik: ok so this is to turn teh registry into a config?
20:34:56 <yogesh_> but the implementaitons are driven with config...
20:34:56 <SlickNik> If I'm understanding this correctly, this is to have a plugin model, so you can just specify the python module for a new implementation of a completely different service_type.
20:34:59 <vipul> seems like if we extracted the registry out to a conf or something like that you could load any arbitrary class
20:35:07 <hub_cap> thats what i think too vipul
20:35:22 <yogesh_> that was the first step vipul
20:35:31 <grapex> yogesh_: Is that we load an image with one single guest agent, on, on loading itself up, it determines what type of agent it should be and loads an arbitrary class by talking back to Trove somehow?
20:35:44 <vipul> yogesh_: ok.. how that class gets into the instance probably doesn't have to be a Trove concern
20:35:51 <yogesh_> yes...
20:35:59 <hub_cap> no i think this is for a impl that stays out of the mainline codebase, right?
20:36:00 <yogesh_> trove doesn't need to contain the implementations as suc
20:36:10 <yogesh_> true...
20:36:23 <yogesh_> that is the final point around this blueprint
20:36:36 <vipul> hub_cap: Yes, assuming you can't put the manager impl in codebase.. how do we allow someone to plug in a manager
20:36:40 <yogesh_> to start with, we move the registry into config...
20:36:41 <hub_cap> i think im ok w that
20:36:46 <yogesh_> and make it directly addressable
20:37:02 <hub_cap> id like to see how it works out in the code itself but i dont think thts a bad idea
20:37:11 <yogesh_> yeah, step-1
20:37:13 <yogesh_> :
20:37:20 <hub_cap> id like to _not_ support every impl for everythign if possible
20:37:33 <hub_cap> then we can remove percona (i kid i kid)
20:37:37 <yogesh_> extracting the base contracts out from mysql implementations into generic base classes
20:37:44 * vipul stabs hub_cap
20:37:46 <SlickNik> I'm for the idea of a plugin model as well.
20:37:47 <hub_cap> HAHAHAHAHA
20:37:51 <yogesh_> :-)
20:37:53 * SlickNik gets out of the way
20:38:13 <hub_cap> ok thats fine. i think this will not make havana tho
20:38:17 <hub_cap> it seems somewhat complicated
20:38:23 <hub_cap> is that ok for the parties involved?
20:38:25 <yogesh_> the first step is not
20:38:26 <vipul> let's do a simpnle thing in Havana
20:38:31 <grapex> Honestly I'm a bit confused...
20:38:33 <vipul> take out the registry into conf
20:38:39 <vipul> so we can load arbitrary managers
20:38:41 <yogesh_> which per me will be to extract the bases classes out...
20:38:48 <grapex> I probably will need to see the code to get this. My guess is it's just a refactor to make things more flexible?
20:38:51 <yogesh_> and have a mysql package, right with the existing code
20:38:56 * cp16net confused as well
20:39:12 <yogesh_> which has extended implementations..
20:39:24 <vipul> grapex: Mysql manager contains stuff other managers might need
20:39:38 <yogesh_> thats correct
20:39:42 <grapex> vipul: Ok, so the idea is make that code reusable, right? I'm for that.
20:39:47 <yogesh_> if we can structure it in the first go...
20:39:54 <vipul> right, but the thing reusing it, might be out of repo
20:40:03 <yogesh_> then brakingit into a pluggable component can be taken up in parts...
20:40:07 <hub_cap> simple way to put it
20:40:09 <hub_cap> turn
20:40:10 <hub_cap> https://github.com/openstack/trove/blob/master/trove/guestagent/dbaas.py#L34
20:40:13 <hub_cap> conf values
20:40:16 <hub_cap> into
20:40:16 <key2> yogesh_: do you have any code or proof of concept to review? it would help to understand
20:40:19 <cp16net> ok i think it just cliked for me...
20:40:28 <yogesh_> i am working on it...almost done...
20:40:32 <yogesh_> i can share...
20:40:43 <vipul> ok... i think we can push out the refactor stuff to past H3
20:40:52 <hub_cap> hehe ya
20:40:57 <vipul> unless we have something concrete ready to go
20:41:08 <vipul> but let's get what hub_cap pointed out done
20:41:09 <vipul> in H3
20:41:18 <hub_cap> if we can easily im all for that
20:41:24 <yogesh_> slightly confused... :-)
20:41:38 <hub_cap> yogesh_: take it offline w vipul
20:41:41 <hub_cap> he knows whats going on
20:41:45 <vipul> push out REGISTRY to conf today..
20:41:45 <hub_cap> soudn good?
20:41:51 <vipul> we can take it offline
20:42:02 <yogesh_> how about the base classes...
20:42:08 <hub_cap> #link https://blueprints.launchpad.net/trove/+spec/support-schema-queries
20:42:13 <yogesh_> thats jsut some refactor..
20:42:16 <vipul> unless we have something ready to go.. we have to defer that til later yogesh_
20:42:27 <hub_cap> is sushil here?
20:42:37 <yogesh_> i am on this bp as well
20:42:41 <hub_cap> ok
20:42:51 <yogesh_> this is for the vertica implementation we are working on
20:42:55 <hub_cap> yogesh_: after the meeting tell me your launchpad id
20:42:58 <hub_cap> and ill assign you
20:43:04 <yogesh_> sure...thanks
20:43:12 <yogesh_> ok
20:43:18 <SlickNik> So what's the bp about?
20:43:38 <hub_cap> so here is my issue w/ things that are specific for a impl that wont be in mainline
20:43:40 <yogesh_> for vertica, the stratgey is to have the create database api map to the schema creations..
20:43:48 <hub_cap> if we dont use the code, its not gonna go in the code. period
20:43:55 <yogesh_> ok...
20:44:15 <hub_cap> if you push this magical vertica impl up, we can add teh code then
20:44:22 <yogesh_> since the code was dependent on the first bp...
20:44:43 <yogesh_> we did not put it in as yet..
20:45:04 <dukhlov> #link https://blueprints.launchpad.net/trove/+spec/configuration-driven-changes
20:45:07 <yogesh_> generally...schema related ops are generic...
20:45:36 <SlickNik> yogesh_: since all of this is being called from your manager impl anyway, what's preventing you from overriding it in your manager impl?
20:45:44 <vipul> any objection to modifying existing 'create database' call to 'create schema'?
20:45:49 <vipul> hub_cap: grapex ^
20:45:50 <dukhlov> bleprint related to moving some db specific parts into configuration
20:45:59 <hub_cap> sure
20:46:01 <grapex> vipul: Just the RPC call?
20:46:07 <vipul> no, the actual SQL command
20:46:09 <hub_cap> but what i mean is
20:46:09 <hub_cap> if you need code in a file, thats depending on a impl that you will not be pushing into the mainline code base
20:46:09 <hub_cap> then you wont be needing that code anywhere as far as im concernd
20:46:09 <hub_cap> and then i will be rejecting that code
20:46:09 <hub_cap> if the mysql code uses that new schema code, then sure it would make sense
20:46:10 <hub_cap> but if only vertica is gonna use it then it doesnt make sense for me to maintain it
20:46:10 <hub_cap> since i dont own vertica impl
20:46:23 * grapex sounds the horn of summoning for Daniel Morris
20:46:27 <yogesh_> sure...
20:46:32 <hub_cap> hahah grapex
20:46:39 <hub_cap> if it doesnt affect the way we work today then its ok
20:46:47 <vipul> yogesh_ let's put up a review modifying existing CREATE DATABSE -> CREATE SCHEMA
20:46:49 <hub_cap> ie, if it looks the same to the end user
20:46:56 <vipul> then you can use that in your manager
20:46:57 <yogesh_> yes...
20:47:05 <hub_cap> but if this changes anything fundamentally in the way the schemas/dbs are created
20:47:12 <grapex> vipul: I'd rather now- it would break users. Maybe for the next iteration?
20:47:14 <hub_cap> then we are modifing the user experience and, no,
20:47:15 <datsun180b> why rename it in the mysql flavor
20:47:24 <vipul> in mysql it don't break a thing
20:47:28 <vipul> since they are ==
20:47:32 <hub_cap> if thats the case then im a-ok w it
20:47:40 <jdbarry> we are working on getting the vertica implementation upstream, fwiw
20:47:54 <vipul> jdbarry ++
20:47:56 <datsun180b> oh well if you want to bring relevant research and test cases to strengthen your argument like that
20:48:15 <SlickNik> jdbarry: that would help resolve a lot of confusion
20:48:15 <yidclare> lol
20:48:16 <yogesh_> by the way, the api still stays same...
20:48:17 <grapex> vipul: Oh, I get it- I misread you, sorry
20:48:30 <hub_cap> yes yogesh_ not worried about the api
20:48:35 <yogesh_> no modifications/changes in user ex for mysql
20:48:36 <vipul> datsun180b: i think if it passes exisitng tests.. we are ok no?
20:48:44 <hub_cap> vipul: likely yes
20:48:46 <vipul> everythin i've heard is it's a synonym
20:48:50 <hub_cap> unless we missed somethign in the tests
20:48:50 <vipul> in mysql
20:48:52 <datsun180b> vipul: hard to convey sarcasm in text, i'm with you already
20:48:53 <hub_cap> imsplitbit: around
20:49:04 <vipul> datsun180b: :D
20:49:10 <hub_cap> CREATE SCHEMA vs CREATE DATABASE in mysql imsplitbit, differences or no?
20:49:29 * hub_cap waits for imsplitbit
20:49:42 <SlickNik> #link http://dev.mysql.com/doc/refman/5.0/en/create-database.html
20:49:52 <imsplitbit> :)
20:50:07 <SlickNik> "http://dev.mysql.com/doc/refman/5.0/en/create-database.html is a synonym for http://dev.mysql.com/doc/refman/5.0/en/create-database.html as of MySQL 5.0.2."
20:50:07 <hub_cap> the docs say "CREATE SCHEMA is a synonym for CREATE DATABASE as of MySQL 5.0.2." imsplitbit
20:50:09 <imsplitbit> schema is the same as database in mysql 5+
20:50:19 <hub_cap> ok then we are good. feel free to change to use
20:50:27 <vipul> ok.. the thing is 'some databases' require you to call CREATE SCHEMA.. which is why yogesh_ needs this
20:50:27 <yogesh_> ok..
20:50:37 <grapex> vipul: That sounds fine.
20:50:40 <vipul> cool
20:50:40 <SlickNik> I'm comfortable with changing this.
20:50:42 <hub_cap> some rdms's ya vipul ;)
20:50:48 <hub_cap> *rdbms
20:50:57 <hub_cap> ie vertica lulz
20:51:13 <SlickNik> hub_cap: watch out or you'll get stabbed again :P
20:51:18 <yogesh_> :-)
20:51:26 <hub_cap> HAHAHA SlickNik
20:51:45 <imsplitbit> I'm fine with it
20:51:50 <hub_cap> moving on
20:51:53 <hub_cap> we are runnin out of time
20:51:55 <hub_cap> #topic Upgrade GA
20:52:01 <hub_cap> #link https://bugs.launchpad.net/trove/+bug/1212413
20:52:02 <vipul> oh yea that was me
20:52:06 <vipul> or saurabhs
20:52:14 <vipul> but we have upgrade() in guest_api
20:52:17 <vipul> but no Impl
20:52:34 <hub_cap> cp16net: ummmm why didnt u add your topic to the meeting!?!?!?!!?!??!?!?!?!?!?!
20:52:35 <vipul> so the proposal is to add an impl... where it's sort of pluggable how you upgrade
20:52:44 * cp16net shrugs
20:52:59 <cp16net> i figured we would talk about it in the open discussion...
20:53:07 <hub_cap> SMH
20:53:11 <vipul> essentially defer the actual upgrade to a script or something that you can place on the instance
20:53:23 <hub_cap> vipul: plugable upgrade is good by me
20:53:29 <vipul> any objections? or any good suggestions on how to do it in public impl?
20:53:32 * hub_cap thinks this is more than a bug tho
20:54:09 <vipul> in the upstream version, just invoking rsync and service restart?
20:54:17 <hub_cap> rsync?
20:54:19 <SlickNik> no objections.
20:54:24 <hub_cap> ya that makes sense
20:54:34 <vipul> ok
20:54:36 <SlickNik> That would be an okay upstream impl, imho
20:54:50 <saurabhs> sounds good
20:55:12 <vipul> ok i'm done
20:55:38 <hub_cap> id like to see an apt based one too
20:55:38 <hub_cap> but i dont think that needs to be done for the first impl
20:55:38 <hub_cap> let someone using apt/rpm do that work
20:55:38 <hub_cap> but plz create a BP for pluggable upgrades
20:55:38 <hub_cap> w/ this info in it
20:55:40 <arborism> isn't the key regen'd after initial rsync, making that an impossibility?
20:56:02 <vipul> arborism: which key? ssh?
20:56:08 <arborism> si'
20:56:11 <hub_cap> shouldnt be arborism
20:56:14 <SlickNik> arborism: I don't think we regen the key.
20:56:15 <vipul> not sure it is
20:56:25 <hub_cap> if thats happening /me thinks its a bug
20:56:31 <arborism> ah, i thought it was, my bad. I'll double-check.
20:56:37 <hub_cap> plz do
20:56:39 <hub_cap> log a bug if so
20:56:40 <hub_cap> <3
20:56:45 <hub_cap> #topic Flavors per Service Type
20:56:47 <hub_cap> we have 4 min
20:56:51 <vipul> crap that's me too
20:56:53 <hub_cap> i like this idea
20:56:55 <hub_cap> fwiw
20:56:55 <vipul> we discussed this yesterday
20:57:10 <vipul> so /flavors?service_tyep=xx
20:57:10 <SlickNik> Yeah, read it over.
20:57:11 <vipul> is that good?
20:57:14 <SlickNik> I think it's a good idea.
20:57:22 <jdbarry> i discussed this with myself yesterday (bot issue)
20:57:23 <KennethWilke> makes sense to me
20:57:24 <hub_cap> ya i think thats the only thing for v1 that'd work
20:57:27 <datsun180b> proposed was adding a ?service_type= filter to the flavors list call IIRC
20:57:28 <hub_cap> jdbarry: lol
20:57:45 <hub_cap> im all for it
20:57:46 <datsun180b> oh vipul's a minute ahead of me
20:57:48 <vipul> datsun180b: correct
20:57:50 <yogesh_> vipu: do u see any change in the api with this
20:58:00 <yogesh_> vipul*
20:58:00 <hub_cap> id like to see us hold more info about the flavors too
20:58:09 <hub_cap> so that we can _not_ go to nova every time we list em
20:58:12 <vipul> probalby just a change to client really.. and some changes to aceept the filter on api side
20:58:21 <vipul> hub_cap: yes!
20:58:21 <hub_cap> and jsut link the name back to the nova flavor
20:58:30 <SlickNik> hub_cap: probably a diff work-item though.
20:58:32 <vipul> kinda sucks we list all the ones found in nova
20:58:37 <yogesh_> can't the falvor taxonomy stays same but they map internally to separate config items
20:58:44 <hub_cap> possibly SlickNik could all be one fell swoop tho
20:58:59 <SlickNik> btw, is this for h3 as well?
20:59:08 <vipul> yogesh_: not really since the flavor contains details about disk size, etc
20:59:14 <SlickNik> I think so, but want to clarify
20:59:18 <hub_cap> ok real quick
20:59:19 <vipul> if we can get it done
20:59:20 <hub_cap> we like this
20:59:22 <hub_cap> blueprint it
20:59:22 <yogesh_> will discuss offline..
20:59:23 <hub_cap> do it
20:59:24 <hub_cap> done
20:59:24 <vipul> ok
20:59:26 <vipul> will do
20:59:29 <hub_cap> #topic open discussion
20:59:35 <hub_cap> cp16net: link your wiki pager
20:59:47 <vipul> what's a wiki pager
20:59:47 <hub_cap> #homework go over cp16net's wiki page
20:59:50 <vipul> oh
20:59:51 <vipul> duh
20:59:57 <cp16net> here is some autmated backup design
20:59:58 <cp16net> https://wiki.openstack.org/wiki/Trove/automated-backup-design
21:00:00 <hub_cap> vipul: cp16net is a wiki drug dealer from 1987
21:00:11 <vipul> heh always had tha suspicion
21:00:15 <cp16net> its an overview and i will continue to add to this
21:00:27 <hub_cap> automated backup design == maintainence window == guest update during maint
21:00:30 <cp16net> :-P
21:00:32 <hub_cap> all that kinda goes together in my mind
21:00:34 <lifeless> Does trove use diskimage-builder's first-boot feature?
21:00:47 <hub_cap> SlickNik: ^ ^
21:00:49 <vipul> lifeless: yes we do
21:00:50 <hub_cap> is it being removed lifeless?
21:00:52 <juice> yes
21:00:54 <SlickNik> lifeless: yes, we do
21:00:55 <lifeless> We want to remove it yes.
21:00:58 <vipul> no!
21:01:00 <vipul> lol
21:01:12 <lifeless> idempotent os-refresh-config scripts are much better
21:01:13 <SlickNik> what's the alternative?
21:01:17 <hub_cap> heh cool. im sure we can work aroudn it w orc
21:01:18 <vipul> we don't need it after we get user-data patch in
21:01:33 <grapex> Sorry guys, I've got to go to a meeting scheduled at 4:00
21:01:38 <hub_cap> yes we are done
21:01:40 <grapex> talk to you all later
21:01:43 <lifeless> they run equally early
21:01:44 <hub_cap> #endmeeting