18:00:27 #startmeeting trove 18:00:27 Meeting started Wed Dec 11 18:00:27 2013 UTC and is due to finish in 60 minutes. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:31 The meeting name has been set to 'trove' 18:00:33 here 18:00:39 present 18:00:48 hello 18:00:51 hello all 18:01:00 o/ 18:01:04 o/ 18:01:08 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:01:10 o// 18:01:12 7o7 18:01:23 o/ 18:01:43 so lets start w/ the fun one 18:01:55 \o\ 18:02:03 o/ 18:02:08 #topic datastore_types before tempest 18:02:12 ? 18:02:16 juice: Doing aerobics? 18:02:20 julim: hip hop horray? 18:02:27 juice: ^ ^ 18:02:29 yup 18:02:32 hub_cap wins 18:02:39 o/ 18:02:49 juice: do i win cuz i said it to someone random instead of u? 18:02:50 o/ 18:03:12 ok so back to the topic at hand 18:03:27 i think that we should allow the existing 3 in before we get around to tempest testing 18:03:35 cassandra, mongo, and redis 18:03:49 +1 18:03:53 ill be running them today and taking a look at all 3 of them to make sure they are quite similar 18:03:54 +1 18:03:56 hub_cap: do we just not gate on them? 18:03:59 id like others to do that as well 18:04:05 So what about tests for them? 18:04:28 Do we gate on them to make sure they're not broken? 18:04:43 kevinconway: we will once we get tempest tests a-goin 18:05:20 We do have datastore_types support now, so we could potentially add to our existing gate and spin up the differnt types 18:05:35 it would add time to our builds.. 18:05:36 o/ 18:05:41 the risk we run is that something changes that doesnt properly get tested on all our impls 18:05:45 o/ 18:06:11 vipul: we can parallelise it w/ tempest (honestly we probably could w/ the present stuff too i just not sure we should spend too much time on it now) 18:06:19 wouldn't the new data stores fail the current integration tests though? 18:06:31 will there be a way to choose tests based on datastore? 18:06:32 i don't think the extra test time should be considered as a deal-breaker 18:06:41 we need image elements asap ! 18:07:01 kevinconway: if you ran *all* tests i'm sure they would because some tests do not apply to all datastores 18:07:13 kevinconway: w/ the tempest tests we will make sure teh different datatypes dont run all the same tests 18:07:23 cp16net, kevinconway that why we have test groups 18:07:27 if resource/time is a factor, we can just gate on one datastore type... maybe one for sql and one for no-sql 18:07:27 denis_makogon: SlickNik is working on that 18:07:31 denis_makogon: yup 18:07:43 SlickNik, any statuses on that ? 18:08:02 denis_makogon: thats not what we are talking about right now :) 18:08:08 there is a topic for that later in the meeting 18:08:11 sorry 18:08:12 so if we merge the new types would we release them before the tempests tests are going? 18:08:14 np 18:08:19 denis_makogon: still working on cleaning up the elements before moving to tripleo 18:08:43 denis_makogon: you can get started writing the tempest tests, though. 18:08:52 ok so, anyone opposed to merging in these impls? 18:08:59 denis_makogon: Shouldn't be a blocker until the final integration point. 18:09:00 hub_cap: ^^ question 18:09:06 SlickNik, Dmitriy Iakunchikov already doing that 18:09:06 kevinconway: go head 18:09:14 kevinconway: so if we merge the new types would we release them before the tempests tests are going? 18:09:18 denis_makogon: any update on that? 18:09:35 SlickNik, lets talk after meeting, ok ? 18:09:36 kevinconway: What do you mean by release? 18:09:44 What's his IRC handle? I can ask him too. 18:09:51 I think having them in as not 100% supported features is ok 18:09:53 sure. 18:09:53 SlickNik, he's out 18:10:00 the alternative is to have them decaying in reviews forever 18:10:07 grapex: as in would they go out in an icehouse release before we tested them 18:10:16 kevinconway: define release them 18:10:27 kevinconway: Yes, I think we should- just tell people not to use them 18:10:32 they are released when they land basically 18:10:50 use at your own risk 18:10:51 "We stand behind the completeness and correctness of this feature--just don't use it!" what? 18:10:52 merged code != fully baked, supported code i think 18:10:58 could we add reddwarf job into trove ? 18:11:16 i dont think its necessary sicne its just a subset of the functionality denis_makogon 18:11:21 datsun180b: Well, part of this is happening because we do have tests, but we don't want to add to them for these features since we're trying to get Tempest up and running first. 18:11:27 we should push forward on tempest and the tasks it takes to get it running 18:11:35 hub_cap, but we'll be able to modify it 18:11:39 gotcha, i'm on the right page now 18:11:47 so as part of each Datastore review, we should be requiring that the README be updated 18:12:01 i don't know where else we document this sort of stuff 18:12:13 vipul, Wiki ? 18:12:29 Also, we need to make sure that they _work_ at the very least. 18:12:43 SlickNik, hup_cap testing them 18:12:55 maybe we need a functionality matrix 18:12:58 on the wiki somewhere 18:13:07 thats a good idea 18:13:08 hub_cap, elaborate 18:13:34 showing what is supported for each datastore 18:13:40 hub_cap: +1 to functionaility matrix 18:13:44 cp16net, oh, yes, agreed +100500 18:13:48 as well as well defined API docs that detail it 18:13:54 :) 18:13:58 and showing what is not fully supported yet 18:14:12 anne gentle and mike a. are ready to help there as soon as you are 18:14:15 demorris, also how to manage trove to run it 18:14:27 kinda like https://wiki.openstack.org/wiki/HypervisorSupportMatrix 18:14:32 vipul, +1 18:14:33 correct, and operators guide would be good 18:14:51 vipul: agreed. 18:14:54 yup 18:15:22 #action Functional Matrix for Datastores 18:15:47 Oh man... updating a matrix like that seems pretty gross. 18:15:47 Why not just say "as of Icehouse, no assurances are given for the non-MySQL datastore types" 18:15:53 then make sure we have tests for all the datastore types after that 18:16:16 even then some things wont' be supported long term right 18:16:19 written in Tempest or whatever 18:16:22 users? backups? 18:16:35 grapex, sound like they are not working, but we let it land to codebase 18:16:48 vipul: Could you go into some more detail on that? 18:17:07 grapex: the User API for redis will never work 18:17:10 like hub_cap said before, merged code isn't necessarily a release in itself 18:17:16 grapex: some nosql thing may never support taking backups 18:17:24 not even a nightly or something like that 18:17:31 So, let me ask you a question. Are there certain sub-teams specifically working on certain implementations? The reason I ask is because, if we're allowing these implementations without tests (or docs), I want to have at least someone responsible for following through on writing these. 18:17:45 vipul, same with users in Cassandra 18:17:51 vipul: I see what you mean 18:18:18 well that's an extension anyway 18:18:21 I'd hate to have code/doc in trove for an impl that's half baked and not fully tested long-tern. 18:18:25 SlickNik, submitter is a guy who response for docs 18:18:29 vipul: Then I think for the different types, it makes sense to say something will never be supported. 18:18:39 SlickNik: if the code is not maintained, its removed 18:18:45 thats always been my stance 18:18:53 Ok... n/m. I agree with you on that vipul. 18:19:02 I thought we were concocting a matrix to list test IOUs. 18:19:02 n+1, if no one ponies up to "fix" issues, then it doesnt need to stay in the code 18:19:08 grapex: sure, i just think the support matrix woudl be good for that 18:19:20 hub_cap, vipul +1 18:19:28 ok so, this i taking a while 18:19:29 *is 18:19:44 do we feel like we can move on now? is there more to this besides, yes, lets do this 18:19:48 and some docs 18:19:48 ok who's doing the matrix 18:19:55 hub_cap: okay, if that's the stance, I'm okay with it. 18:20:05 ill start the matrix today vipul w/ just mysql 18:20:11 hub_cap, nice =) 18:20:17 hub_cap, <3 18:20:20 and the maintainers of the code for each service can add what they have 18:20:27 sounds good 18:20:37 sound like perfect plan 18:20:48 we will have to make sure thats updated each time things are added to the code 18:20:53 ok moving on 18:20:56 hub_cap: I wonder if we can generate the matrix from the code somehow. 18:21:19 grapex, that would be not easy ... 18:21:21 #topic mount_point and storage directory dependency 18:21:24 until then the wiki better state that no one can be told what the matrix is 18:21:30 grapex: im not that worried about it :) 18:21:30 SlickNik, it's our turn 18:21:35 go go go guys 18:21:41 put up your #links too :) 18:21:51 datsun180b: No one can be told what the working feature matrix is... they have to run the code for themselves. 18:21:52 Okay, so this one is based on a discussion I was having with denis_makogon 18:22:02 #link https://review.openstack.org/#/c/57189/ 18:22:03 #link https://review.openstack.org/#/c/57189 18:22:08 for context. 18:22:26 we need to brink dependency between mount_point and datastore 18:22:36 i mean database data_dir 18:22:55 I'm not sure I like forcing the mount_point and the data_dir to be the same, and this might limit some configurations (where data_dir is not the mount point, but a directory contained within it for example). 18:22:56 for now trove allows to make next misconfiguration 18:23:12 when do we start taking a stance on backwards-incompatible changes to the RPC api 18:23:13 mount_point = /mnt/ , data_dir = /var/lib/mysql 18:23:38 vipul: That's another reason I don't like this change. 18:24:00 you might want to store both the database, and the binlogs on the volume for instance. 18:24:08 vipul SlickNik: Are you referring to the RPC API or the trove/guestagent/api methods? 18:24:13 that is why i suggested ikhudoshyn to make such patch 18:24:35 grapex: trove/guestagent/aip 18:24:37 which retrieves data_dir from my.cnf and mounts volume into it 18:24:51 maybe we can wait for that conversation grapex 18:25:02 let denis_makogon and SlickNik do their thing 18:25:22 vipul SlickNik: I say we keep allowing it to change wily-nilly until the reference guest moves to its own repo. 18:25:26 * grapex evil laugh 18:25:36 i suggest to make strict dependency between mount point and database data directory 18:25:46 Another reason I don't like this change is because it would mean that the guestagent now has to understand how to parse every datastore config file, and know what value corresponds to the equivalent of a mount_point. 18:26:02 SlickNik, it's already knows how to do that 18:26:14 example: admin password 18:26:20 vipul SlickNik: No, I guess it could cause some pain. We should probably discuss this soon- what I'd like to see is for guestagent/api.py to support calling older versions of the agent within reason. There should be an expectation that the agents can eventually update themselves though, so for instance they'd never be more than a week or so out of date. 18:26:30 for mysql it does. What's the corresponding data_dir value for redis/cassandra? 18:26:59 SlickNik: In theory, the data_dir for redis and caddandra could come from config values. 18:27:01 SlickNik, it's very easy 18:27:02 data_dir in redis is currently hard coded to /var/lib/redis 18:27:11 SlickNik: Though I agree the data dir and mount directory should not have to be the same. 18:27:12 it doesnt parse the config file it just appends 18:27:15 theres a differnce 18:27:17 for cassandra /var/lib/cassandra/data 18:27:27 does every datastore have a data_dir setting? 18:27:32 vipul, yes 18:27:39 vipul, everyone has 18:27:42 My point though is that the app, which has the get_data_dir() method, could have subclasses for different datastore types. 18:27:47 cp16net, not only appends 18:28:04 cp16net, somewhere in code it reads admin pass from my.cnf 18:28:10 yea i don't think you should limit what you mount to 18:28:30 you may have >1 things you want to mount in the future as well 18:28:38 vipul, but it need to be chained 18:28:38 Sounds like everyone agrees that mount_point doesn't necessarily have to be the same as the data dir, right? 18:28:44 grapex: +1 18:28:53 lol in redi sits just called "dir" 18:28:54 grapex: yes, I think so. 18:29:02 dir /var/lib/redis 18:29:05 Let's just make a it a config value. Would there be some case where that wouldn't work? 18:29:10 vipul, how to be if mount_point is /dev/null and data_dir = /var/lib/mysql 18:29:16 vipul, try to backup it 18:29:27 denis_makogon: that's a bad configuration then 18:29:37 vipul, because of bad design 18:29:39 i think if you've got enough bullets and point the gun earthward, shooting yourself in the foot is your fault 18:29:41 denis_makogon: That's bad configuration 18:29:46 SlickNik: vipul do you have a specific reason to have data_dir != mount point? 18:29:48 tha'ts /dev/null as a service 18:29:54 another datastore we will supoprt 18:30:03 vipul: write-only memory. there's an ancient joke RFC for it 18:30:05 thats the fastest 18:30:25 and sharded 18:30:36 i dont like whole idea of keeping 2 values for writing data 18:30:56 if there is no good reason to have a different directory right now then im not sure why we'd keep 2 values 18:31:08 i see a wayout - mysql/config.template : {{mount_point}}/data_dir 18:31:11 hub_cap: 1. you lose the flexibility of possibly storing > 1 type of object on your volume. 18:31:42 another: reading from conf file 18:31:46 (for example if you want your volume to store databases as well as something like binlogs, for example) 18:31:50 but do we ever watn to do that SlickNik ? 18:31:59 SlickNik, {{mount_point}}/data_dir 18:32:08 root directory 18:32:21 hub_cap: I could see potntially trove having a secondary volume for some things that are not data 18:32:29 Real quick question for vipul / SlickNik: When we're talking about "mount_point", are you guys mixing that up with the "data_dir" variable used throughout the backup code too? 18:32:36 Yes, you probably don't want to store it on the root partition, because it will grow (you might need them for incremental backups say). 18:32:36 data_dir and mount_point __should__ be dependent 18:32:55 Because previously that "data_dir" var was named "mount_point" 18:32:58 vipul, why do we need more then one volume ?? 18:32:59 denis_makogon: They are _dependent_. They are just not the same value. 18:33:00 ya i think thats a fair point SlickNik 18:33:20 SlickNik, now they are not dependent 18:33:31 grapex: No, i think currently we're consistent that mount piont = data_dir for the most part 18:33:39 i just don't think it's a good limitation to impose 18:34:05 o/ 18:34:17 welcome imsplitbit 18:34:21 sorry I'm late 18:34:24 try to run trove with mount_point /var/lib 18:35:12 or another way - we need N sections in trove-taskmanager.conf where different datastore will have it's own mount_point 18:35:16 so i think we can make it optional, to send the value in a conf if it exists 18:35:22 Ok- so I'm game to just change line 97 of this review to say "mount_point = some config value" and then replace the proceeding instances of "data_dir" in the prepare function to "mount_point": https://review.openstack.org/#/c/57189/16/trove/guestagent/datastore/mysql/manager.py 18:35:44 With the exception that before doing a restore 18:36:05 On line 112, we need to actually pass the _perform_restore function the data_dir, and not the mount_point 18:36:06 so lets do this, make it optional denis_makogon, if they want to declare a mount_point they can 18:36:37 and maybe its time we start thinking about putting these things into [cassandra][mysql] sections 18:36:41 hub_cap, so then we need N oslo parameters groups 18:37:05 the second issue with this patch.. why change the signature of the prepare() API 18:37:21 vipul: if somethign is not being used... 18:37:31 hub_cap, +1 18:37:33 we need ot have a deprecation strategy or some way to version 18:37:34 hub_cap / grapex: I'd be okay with either of your suggestions. 18:37:39 i know it is sucky for deployment, so i suggest we fix versioned messages 18:37:44 this doesn't work when you have and old version 18:37:55 #action Start delivering more oslo.config parameters groups 18:38:12 vipul: yup, and i think we need to fix it in production.. iirc rax deals w/ this every deploy too :) 18:38:28 denis_makogon: we're still talking about the guest API change, hold your horses. 18:38:39 hub_cap: trove should deal with this.. like every other openstack project is trying to do 18:38:48 don't just break compatibility 18:38:51 SlickNik, API would be never changed in this case 18:38:58 vipul: i agree trove should handle it :) 18:39:07 denis_makogon: That patch out there changes the API 18:39:27 SlickNik, i'm talking about multiple oslo groups 18:39:33 we cant say "no one can make the code better until we deal w/ versioned messages" and then no one deal w/ versioned messages 18:39:50 hub_cap, agreed 18:40:08 lets do not touch API 18:40:16 lets make inner code better 18:40:27 sure i get that.. but there are ways of doing this w/o breaking compat.. allow the param to be passed in and overridden by guest.conf 18:40:33 hub_cap: the question is - do we take breaking changes to the API before we have a method to deal with versioned messages? 18:40:36 denis_makogon: the guest api _is_ an api though 18:40:59 SlickNik: weve done it many times before :) 18:41:10 So I want to point out we've had to deal with breaking changes in the RPC calls for a long time now. 18:41:12 but we are really bogged down w/ this 18:41:18 I think we should fix it, but this problem is hardly new. 18:41:21 And felt the pain many times before too. :) 18:41:24 yes rax deals w/ it every release hahah 18:41:33 gosh, when's the last time i broke some rpc calls everywhere, when was it... 18:41:35 grapex: not saying it's new.. jsut something we need to start getting better at gating on 18:41:46 +1 18:41:49 something about backing... maybe hiccups? can't recall 18:41:53 yes but we need someoene to pony up and do the work too 18:42:06 that'd be like us not allowing cassandra until tempest hehe 18:42:07 * imsplitbit points at hub_cap 18:42:08 vipul: Agreed- I just wonder if its a good reason to hold up this particular pull request. 18:42:19 but srsly we need to mvoe on 18:42:27 moving on 18:42:30 we will not get thru this meeting hehe 18:42:40 hub_cap, not even once 18:42:47 grapex: based on what we talke about .. we could probably not break api and get this in with a little rewuire 18:42:49 rewrite 18:42:54 lets table this until after the meeting is over though vipul grapex SlickNik denis_makogon 18:43:02 ok move on 18:43:07 vipul: in golang? 18:43:10 rewrite? 18:43:12 :) 18:43:17 #topic guidestyle 18:43:19 go denis_makogon 18:43:32 sounds good. Let's come back to this later. 18:43:33 #link https://review.openstack.org/#/c/60277/ 18:43:43 #link https://review.openstack.org/#/c/60276/ 18:43:51 we need to deal with this, both 18:44:05 I'm cool with it 18:44:13 __init__.py - hacking already had rules for that 18:44:29 the vim guys might freak 18:44:31 denis_makogon: im ok w this too, the openstack mailing list has talked about this too 18:44:32 i vote we add jslint validation to our code 18:44:38 #vim - reason, i can edit code without vim, why do i need #vim lines in code 18:44:39 vipul: i'm a vim guy, idgaf 18:44:45 vipul: only if they code in goofy vim spacing 18:44:46 ok then! 18:44:47 i have my own settings 18:44:49 #link http://openstack-dev.markmail.org/search/?q=modeline#query:modeline+page:1+mid:2a55it3usuqsfsif+state:results 18:45:01 datsun180b: you're doing it wrong 18:45:03 ok good moving on then! 18:45:10 go go go 18:45:10 no emacs vs vim imsplitbit 18:45:12 jslint will hurt your feelings 18:45:13 I'm good 18:45:16 :) 18:45:20 I wasn't gonna start 18:45:24 #topic updating requirements 18:45:26 imsplitbit: ;) 18:45:26 imsplitbit: i don't judge. i leave that for vengeful Bram Moolenaar 18:45:27 just a friendly jab 18:45:28 moving one 18:45:29 denis_makogon: gogogogo 18:45:34 #link https://bugs.launchpad.net/trove/+bug/1259938 18:45:53 I feel like this bug is too general 18:45:57 what are you think about dropping mockito out ? 18:46:06 +100000000000 18:46:07 +1 w/ grapex 18:46:07 I don't know if something like this should be a bug. 18:46:15 so lets first talk about dropping mockito 18:46:17 I marked it as incomplete 18:46:19 thats a simple one, lets drop it 18:46:19 hub_cap: Ok 18:46:20 +four 18:46:26 +1 18:46:28 +5000 18:46:29 +1 18:46:29 grapex, trove unit tests have more than 1000 incorrect assertions 18:46:30 +infinity 18:46:32 + 18:46:38 'incorrect' 18:46:39 lol 18:46:43 denis_makogon: ? 18:46:43 do we have an official replacement? 18:46:46 denis_makogon: How so? 18:46:51 imsplitbit: Mock? 18:46:53 denis_makogon: Can you give some examples? 18:46:54 mox? 18:46:59 mox, mock 18:47:13 no mox 18:47:15 denis_makogon: no moc 18:47:16 lol that was fast 18:47:17 yes mock 18:47:18 mox* 18:47:18 please let me take this up with lifeless and openstack 18:47:20 I propose we write a Trove specific mock framework and call it Taquito. 18:47:37 ba dum dum 18:47:39 grapex: i'll start on the bash code 18:47:39 juice: do it! 18:47:41 yum 18:47:57 #link https://github.com/openstack/trove/search?q=assertEqual&ref=cmdform - huge part of all assertions are wrong 18:48:06 juice: Our mockito evangelist 18:48:11 indeed 18:48:18 I say we table the mocking framework discussion until juice has a conversation with lifeless / ML 18:48:28 why? 18:48:28 SlickNik, agreed 18:48:31 SlickNik: Sure, agreed. 18:48:39 that is why i putted it into agenda 18:48:42 * imsplitbit is curious 18:48:44 what's wrong with testcase.assertEqual? 18:48:47 I don't get why it matters- how much pain is there really to adding it. 18:48:58 yea i'm confused why these are 'wrong' 18:49:05 datsun180b, incorrect parameters order 18:49:31 i personally like the assertThat matchers but I wouldn't go back and change anything 18:49:32 we should not use Is, KeysEqual, Not etc 18:49:45 what's the correct form then? 18:49:45 denis_makogon: I feel like in JUnit the order being wrong could really screw up the error messages 18:49:59 denis_makogon: http://docs.python.org/2/library/unittest.html#unittest.TestCase.assertEqual 18:50:01 but in Python I feel like if if you mismatch "expected" and "actual" it doesn't affect anything 18:50:18 ohh it's just expected/actual 18:50:21 grapex, but it's not correct 18:50:24 there is no expected actual 18:50:26 just the error message grapex 18:50:31 robertmyers: Great find 18:51:05 how about just use 'assert thing1 == thing2, "ITS NOT THE SAME!!!!"' 18:51:08 i'd like to make call _correct_ assertions 18:51:21 denis_makogon: define correct 18:51:29 that doesnt change anything 18:51:31 denis_makogon: are you proposing to change assert(a, b) to assert(b, a) ? 18:51:37 I don't know if I want to make a big deal out of this 18:51:41 in 1000 places? 18:51:45 testtools allow as to use assertIn, assertIs, assertIsInstance 18:52:01