20:00:08 #startmeeting trove 20:00:09 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:12 The meeting name has been set to 'trove' 20:00:22 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 20:00:31 o/ 20:00:36 hub_cap: refresh if you haven't 20:00:44 \\o// 20:00:55 o/ 20:00:58 woah kevinconway 20:01:03 ok there was only 1 action item called DOC DOC DOC 20:01:12 kevinconway: are you doc oc? 20:01:15 o/ 20:01:39 o^/ 20:01:39 o/ 20:01:40 i think we are still being kinda lax on the doc standards we proposed 20:01:47 I haven't seen that many more docstrings. 20:01:54 o/ 20:01:58 but thats ok, we will get better at screaming at people in gerrit 20:02:02 SlickNik: Is there a way to get Gerrit to enforce that? 20:02:05 ya SlickNik ive approved reviews w/o even looking... 20:02:06 I'll try to keep that in mind 20:02:13 Honestly I forgot all about it... :( 20:02:14 grapex: not that I know of. 20:02:16 no grapex.. gerrit enfoces nothing... 20:02:29 wed have to write someting custom to get zuul / jenkins to enfoce it 20:02:29 That's the problem with Gerrit, the lack of sentient thought 20:02:29 Yeah, I'm going to start pushing back on code reviews because of it. 20:02:36 ya we should SlickNik 20:02:43 ok so lets skip to the next item 20:02:45 hub_cap: pylint has an option to error if missing a doctstring. it would be retroactive for all code though 20:02:47 o/ 20:02:47 * KennethWilke takes note... add sentience to gerrit 20:02:56 kevinconway ;) 20:03:03 kevinconway: I wonder if Zul has some trick where pylint would just apply to the diff 20:03:28 lets not worry about it. Core team... do our job ;) 20:03:31 we will enforce it manually 20:03:35 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 HAH 20:03:46 #topic clustering api update 20:03:48 imsplitbit: tag 20:03:58 datsun180b: Then you have to add docstrings explaining why it's broken :) 20:04:07 ok 20:04:17 #link https://review.openstack.org/#/c/41993/ 20:04:17 #link https://review.openstack.org/#/c/41995/ 20:04:24 clustertypes api 20:04:28 i say turn on the firehose and deal with the mess once instead of incrementally forever 20:04:31 and support for it in troveclient 20:04:40 please review 20:04:40 woah nice.. didn't see these before 20:04:48 cause they just went up :) 20:04:56 they appeared recently :) 20:05:03 imsplitbit: do they have docstrings? 20:05:05 =) 20:05:08 of course 20:05:20 I'll be working on the cluster api tonight 20:05:25 hopefully it won't take as long 20:05:33 I think I got the api stuff figured out 20:05:48 this was my first foray into the world of the api 20:05:54 you survived 20:06:06 yep 20:06:09 so are you going to submit the cluster api without impl? 20:06:15 yes 20:06:18 is it cool to return no-op? 20:06:22 then I'll submit an impl 20:06:35 woo we got our first reviews to not make the Havana release ;) 20:06:35 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 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 #action imsplitbit to move his clustering reviews to a feature branch 20:06:39 #link https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches 20:06:46 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 :) 20:06:56 yup, agreed 20:07:26 thats all I got to say about that 20:07:27 ya hes gonna push them to a feature branch and the 2nd review will cover that part 20:07:34 cool great work 20:07:43 MANY people are interested in clustering 20:07:43 Agreed on the feature branch piece. (And the non-havana part too) 20:08:13 ok so moving on 20:08:13 #topic h3 update 20:08:15 #link https://launchpad.net/trove/+milestone/havana-3 20:08:30 we are looking good for h3 still 20:08:44 only 1 bug thats not fixed 20:08:55 and 0 bps that are _not_ in progress 20:09:05 nice 20:09:13 https://bugs.launchpad.net/trove/+bug/1199507 is not assigned to anyone yet. 20:09:28 and for some reason its only a "medium" 20:09:30 interesting 20:09:30 Looks fairly straightforward though. 20:09:33 what happens between H-3 (9/5) and summit 20:09:48 vipul: we go on break 20:09:53 woohoo! 20:09:54 ever seen summer school? 20:09:57 holiday! 20:10:00 hub_cap there says there is a review for it 20:10:01 we are the guy whos zipper got stuck 20:10:12 507 that is and you are the one who worked on it 20:10:23 juice: thats VERRRRY odd 20:10:41 hub_cap: why is this a bug though 20:10:50 i did'nt think trove supported reset_password 20:10:51 #action hub_cap to review https://bugs.launchpad.net/trove/+bug/1199507 20:10:55 you just enable root multiple times 20:11:08 wait this should be in troveclient 20:11:11 vipul, I think it should be a cli bug 20:11:13 yup 20:11:13 Available actions for 'instance' cmd: 20:11:16 reset_password Reset the root user Password 20:11:34 moved to python-troveclient 20:11:38 seems like its missplaced 20:11:40 thx SlickNik 20:11:43 #undo 20:11:44 Removing item from minutes: 20:11:54 sounds good, carry on 20:11:56 def 20:11:58 moving on 20:12:14 ok feature freeze info is gonna be fun 20:12:20 #topic feature freeze 20:12:28 #link https://wiki.openstack.org/wiki/FeatureProposalFreeze 20:12:34 #link https://wiki.openstack.org/wiki/FeatureFreeze 20:12:46 we have a tentative feature freeze for Sep4, just liek the other projects 20:13:06 the feature proposal freeze should happen sooner, but no date is set 20:13:09 this is a dry run 20:13:14 we are not 100% solid on this 20:13:20 we can have stuff slip in 20:13:33 for instance, heat support _has_ to get in, and it wont make the FPF 20:13:40 so real quick 20:13:53 FPF means if its not on review.openstack.org, its not going in h3 20:14:04 FF means if its not a bug, its not going in 2013.1 20:14:15 FF also means h3 gets cut 20:14:28 so we are officially in FPF now 20:14:35 and then we go into the cycle of RC's to determine our "bug free (lol)" 2013.1 releas 20:14:49 we havent set the date vipul... so we are in FPF limbo 20:14:56 i still want to see those items in h3 impl'd 20:15:04 so i think we are going to be lax on FPF this go-round 20:15:10 it says one or two weeks ahead of FF 20:15:27 but yes, if we were 100% obeying, sometime next wk would be FPF 20:15:47 kk 20:15:49 meaning if its not already proposed on gerrit, its not going into h3 20:15:53 unless its a bug of course 20:16:16 then we hit FF and NOTHING thats not a bug goes in till we get 2013.1 cut 20:16:38 so when i joked about imsplitbit's feature eariler its because he would be a good candidate for the FF 20:16:44 and we can leave it unmerged 20:16:57 man so nothing until Nov. 20:16:57 #action hub_cap to find out what happens w/ reviews that land after FF 20:17:02 #undo 20:17:03 Removing item from minutes: 20:17:09 #action hub_cap to find out what happens w/ feature based reviews that land after FF 20:17:21 does that make sense to everyone? 20:17:24 any questions? 20:17:33 yes, that makes sense. 20:17:33 im giong to be strict on some things, but not everything 20:17:36 sounds good 20:17:50 makes sense 20:18:08 cool. if no one has any Qs then we can move on 20:18:09 the freeze sounds… ice 20:18:16 *nice 20:18:19 if you think you are wrongly FF'd then plz talk to me 1x1 20:18:22 its ice too kevinconway 20:18:27 :) 20:18:57 what about teally big features like Cassandra support? 20:18:58 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 *really 20:19:20 key2: id LOVE to see cassandra support ;) but not in Havana 20:19:30 we are way to far along for cassandra now 20:19:55 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 kinda sucks it's 2 months! 20:20:19 well its not vipul 20:20:19 from H3 -> 2013.1 20:20:24 it would be interesting 20:20:26 once we cut a 2013.1 release 20:20:35 key2: hell ya it will. /me wants some cassandra! 20:20:44 )) 20:20:49 lisp? 20:21:00 if we deem there are no critical bugs in the code we can decide to cut 2013.1 vipul 20:21:02 smile :) 20:21:05 we can cut early 20:21:10 key2 :P 20:21:12 hub_cap: oh ok.. then that's coo 20:21:20 * hub_cap assumes vipul ;) 20:21:30 i doubt we have 2 mo of bugs to work out 20:21:45 we can figure that out once we get closer to that date. 20:22:03 unless i push puro crap up for heat support 20:22:08 exactly SlickNik 20:22:14 moving on? 20:22:19 yessir 20:22:26 sounds good 20:22:34 #topic redstack vs devstack users 20:22:40 so real quick let me splain 20:22:52 we have a set of users (radmin for sure) that we use in redstack 20:23:43 this is different from the ones that devstack uses 20:23:43 so when i ./redstack rd-client instance create 20:23:43 then 20:23:43 . ~/devstack/openrc && nova list 20:23:43 i see nothing 20:23:43 because they are on different tenants 20:23:47 robertmyers: has mentioned issues as well w/ horizon integration wrt our users vs devstack users 20:23:58 so im going to rip out the extra users and use the devstack users in redstack 20:24:07 and hopefully including the tests (on pass one) 20:24:15 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 and our tests aren't trying to call the users by name deliberately 20:24:23 if the tests end up failing miserably im going to push a WIP review up for someone else to finish 20:24:34 hub_cap: Sounds good enough 20:24:42 isn't there a requirement to have a role added? 20:24:54 or will existing users just work with trove 20:25:00 yup thats the hope datsun180b that it doesnt fail miserably 20:25:01 i think boss/chunk will still be created/used for specific tests 20:25:03 this is for the main user thats run thru 20:25:15 vipul: is there a req? 20:25:31 hub_cap: i said "i agree" but i took two lines to do it 20:25:33 thought so.. i could be wrong 20:25:33 yes, vipul is right. 20:25:59 You'd have to add the trove role to the existing devstack users, I think 20:26:01 https://gist.github.com/hub-cap/6235210 20:26:19 thats the list of roles i have currently in my devstack+redstack install 20:26:47 i think we need at least one, maybe two admin users, and at least two non-admin users 20:26:59 datsun180b: we can let redstack deal w/ those 20:27:02 It might work for admin, but wouldn't work for guest. 20:27:08 but those arent the ones that ./redstack rd-client uses 20:27:27 the primary reasoning was to align the cli calls between us and devstack 20:27:35 when you source openrc 20:27:39 hub_cap: So really, it's just getting rid of radmin and replacing it in the tests with the demo user? 20:27:43 hub_cap: the bug you linked is something different though 20:27:45 We can just add the role to the devstack users though. They will _always_ exist. 20:27:53 it is, i havent created a bug for this yet vipul 20:27:58 ah ok 20:27:59 this is another thing that needs knocking out tho 20:28:08 you can do a heat stack-list and its different from ./redstack rd-client 20:28:19 so when i get to testing (and when robertmyers is testing horizon) its teh suck 20:28:35 im not sure exactly waht it entails grapex but i think the answer is yes 20:28:39 as part of our devstack patch.. SlickNik do we assign the role ot any existing? 20:28:49 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 yes, it is a little silly to have our own special users 20:29:03 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 vipul: only the ones we create (not the default devstack ones) 20:29:16 but I agree that the devstack created demo user should be used for the tests. 20:29:48 vipul: same behavior in redstack 20:29:58 SlickNik: ok, cool.. 20:30:13 so now that we'll be official devstack.. safe to change existing users i'd imagine 20:30:23 yes 20:30:34 for now ill just mirror what devstack is using 20:30:38 frankly, all the projects use demo 20:30:47 thats what the openrc sets 20:30:51 yes 20:30:55 that works 20:31:00 :) 20:31:01 hub_cap: +1 20:31:10 I like the idea of removing radmin, and adding the "trove" role to admin and demo. 20:31:12 we can let SlickNik figure out the nuances w/ his devstack review ;) 20:31:24 that I can do. :) 20:31:34 cool SlickNik maybe just do that in the devstack review now 20:31:41 so its not merged w/ radmin 20:31:48 good everyone? 20:31:59 sounds good. 20:32:28 #topic blueprints 20:32:30 #action SlickNik update devstack review to add role to default devstack users. 20:32:40 #link https://blueprints.launchpad.net/trove/+spec/pluggable-db-implementations 20:32:44 This is on further abstraction of guestagent for implementing specific database managers... 20:32:46 yogesh_: around? 20:32:49 cool 20:32:51 yes.. 20:32:52 can u explain a bit? 20:33:01 i guess answer this 20:33:05 how do we not do that today? 20:33:28 today we have a generic api + XXX.py impl. coudl be redis, could be mysql, could be cassandra ;) 20:33:32 the idea is to separate the manager implementations from trove 20:33:34 how does that not work 20:33:40 If i read correctly, it seems we need the ability to load a different package? 20:33:42 we have that already yogesh_ 20:33:49 hub_cap: You need to be part of a registry today. 20:34:11 we can not plug any db implementation of the manager in... 20:34:42 if the design goes like, having the contracts sty in trove.. 20:34:49 SlickNik: ok so this is to turn teh registry into a config? 20:34:56 but the implementaitons are driven with config... 20:34:56 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 seems like if we extracted the registry out to a conf or something like that you could load any arbitrary class 20:35:07 thats what i think too vipul 20:35:22 that was the first step vipul 20:35:31 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 yogesh_: ok.. how that class gets into the instance probably doesn't have to be a Trove concern 20:35:51 yes... 20:35:59 no i think this is for a impl that stays out of the mainline codebase, right? 20:36:00 trove doesn't need to contain the implementations as suc 20:36:10 true... 20:36:23 that is the final point around this blueprint 20:36:36 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 to start with, we move the registry into config... 20:36:41 i think im ok w that 20:36:46 and make it directly addressable 20:37:02 id like to see how it works out in the code itself but i dont think thts a bad idea 20:37:11 yeah, step-1 20:37:13 : 20:37:20 id like to _not_ support every impl for everythign if possible 20:37:33 then we can remove percona (i kid i kid) 20:37:37 extracting the base contracts out from mysql implementations into generic base classes 20:37:44 * vipul stabs hub_cap 20:37:46 I'm for the idea of a plugin model as well. 20:37:47 HAHAHAHAHA 20:37:51 :-) 20:37:53 * SlickNik gets out of the way 20:38:13 ok thats fine. i think this will not make havana tho 20:38:17 it seems somewhat complicated 20:38:23 is that ok for the parties involved? 20:38:25 the first step is not 20:38:26 let's do a simpnle thing in Havana 20:38:31 Honestly I'm a bit confused... 20:38:33 take out the registry into conf 20:38:39 so we can load arbitrary managers 20:38:41 which per me will be to extract the bases classes out... 20:38:48 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 and have a mysql package, right with the existing code 20:38:56 * cp16net confused as well 20:39:12 which has extended implementations.. 20:39:24 grapex: Mysql manager contains stuff other managers might need 20:39:38 thats correct 20:39:42 vipul: Ok, so the idea is make that code reusable, right? I'm for that. 20:39:47 if we can structure it in the first go... 20:39:54 right, but the thing reusing it, might be out of repo 20:40:03 then brakingit into a pluggable component can be taken up in parts... 20:40:07 simple way to put it 20:40:09 turn 20:40:10 https://github.com/openstack/trove/blob/master/trove/guestagent/dbaas.py#L34 20:40:13 conf values 20:40:16 into 20:40:16 yogesh_: do you have any code or proof of concept to review? it would help to understand 20:40:19 ok i think it just cliked for me... 20:40:28 i am working on it...almost done... 20:40:32 i can share... 20:40:43 ok... i think we can push out the refactor stuff to past H3 20:40:52 hehe ya 20:40:57 unless we have something concrete ready to go 20:41:08 but let's get what hub_cap pointed out done 20:41:09 in H3 20:41:18 if we can easily im all for that 20:41:24 slightly confused... :-) 20:41:38 yogesh_: take it offline w vipul 20:41:41 he knows whats going on 20:41:45 push out REGISTRY to conf today.. 20:41:45 soudn good? 20:41:51 we can take it offline 20:42:02 how about the base classes... 20:42:08 #link https://blueprints.launchpad.net/trove/+spec/support-schema-queries 20:42:13 thats jsut some refactor.. 20:42:16 unless we have something ready to go.. we have to defer that til later yogesh_ 20:42:27 is sushil here? 20:42:37 i am on this bp as well 20:42:41 ok 20:42:51 this is for the vertica implementation we are working on 20:42:55 yogesh_: after the meeting tell me your launchpad id 20:42:58 and ill assign you 20:43:04 sure...thanks 20:43:12 ok 20:43:18 So what's the bp about? 20:43:38 so here is my issue w/ things that are specific for a impl that wont be in mainline 20:43:40 for vertica, the stratgey is to have the create database api map to the schema creations.. 20:43:48 if we dont use the code, its not gonna go in the code. period 20:43:55 ok... 20:44:15 if you push this magical vertica impl up, we can add teh code then 20:44:22 since the code was dependent on the first bp... 20:44:43 we did not put it in as yet.. 20:45:04 #link https://blueprints.launchpad.net/trove/+spec/configuration-driven-changes 20:45:07 generally...schema related ops are generic... 20:45:36 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 any objection to modifying existing 'create database' call to 'create schema'? 20:45:49 hub_cap: grapex ^ 20:45:50 bleprint related to moving some db specific parts into configuration 20:45:59 sure 20:46:01 vipul: Just the RPC call? 20:46:07 no, the actual SQL command 20:46:09 but what i mean is 20:46:09 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 then you wont be needing that code anywhere as far as im concernd 20:46:09 and then i will be rejecting that code 20:46:09 if the mysql code uses that new schema code, then sure it would make sense 20:46:10 but if only vertica is gonna use it then it doesnt make sense for me to maintain it 20:46:10 since i dont own vertica impl 20:46:23 * grapex sounds the horn of summoning for Daniel Morris 20:46:27 sure... 20:46:32 hahah grapex 20:46:39 if it doesnt affect the way we work today then its ok 20:46:47 yogesh_ let's put up a review modifying existing CREATE DATABSE -> CREATE SCHEMA 20:46:49 ie, if it looks the same to the end user 20:46:56 then you can use that in your manager 20:46:57 yes... 20:47:05 but if this changes anything fundamentally in the way the schemas/dbs are created 20:47:12 vipul: I'd rather now- it would break users. Maybe for the next iteration? 20:47:14 then we are modifing the user experience and, no, 20:47:15 why rename it in the mysql flavor 20:47:24 in mysql it don't break a thing 20:47:28 since they are == 20:47:32 if thats the case then im a-ok w it 20:47:40 we are working on getting the vertica implementation upstream, fwiw 20:47:54 jdbarry ++ 20:47:56 oh well if you want to bring relevant research and test cases to strengthen your argument like that 20:48:15 jdbarry: that would help resolve a lot of confusion 20:48:15 lol 20:48:16 by the way, the api still stays same... 20:48:17 vipul: Oh, I get it- I misread you, sorry 20:48:30 yes yogesh_ not worried about the api 20:48:35 no modifications/changes in user ex for mysql 20:48:36 datsun180b: i think if it passes exisitng tests.. we are ok no? 20:48:44 vipul: likely yes 20:48:46 everythin i've heard is it's a synonym 20:48:50 unless we missed somethign in the tests 20:48:50 in mysql 20:48:52