18:13:08 #startmeeting trove 18:13:09 Meeting started Wed Dec 18 18:13: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. 18:13:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:13:13 The meeting name has been set to 'trove' 18:13:15 wow that was dumb 18:13:24 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:13:29 /0\ 18:13:33 o/ 18:13:35 o/ 18:13:41 o/ 18:13:47 |o| 18:13:47 o/ 18:13:50 o7 18:14:04 #topic Datastore compat matrix 18:14:14 #link https://wiki.openstack.org/wiki/Trove/DatastoreCompatibilityMatrix 18:14:23 o/ 18:14:30 grandiose term for 'drop list' 18:14:33 ive started it, id like the persons who are working on cassandra/redis/mongo to fill out (or correct) whats there 18:14:41 or not.. 18:14:44 datsun180b: u know me, im all about grandiose 18:14:50 kiall: its a-workin for us 18:15:10 ;) 18:15:20 looks good for now 18:15:34 so tehre isint really much to talk about wrt this... 18:15:37 hub_cap: was the lag ;) I saw your start, but took like 3 minutes for the bot's response to come 18:15:38 I notice pgsql is missing (is anyone even working on that yet?) 18:15:47 kiall: wow damn 18:15:57 * hub_cap thinks its your side of the world 18:16:12 we did have a pgsql poc for a bit at one time. 18:16:37 SlickNik: yup kevinconway 18:16:55 yes, i will update the matrix 18:17:44 ok time to move on 18:17:49 cool, thanks kevinconway 18:18:07 #topic datastores logfiles 18:18:14 o/ 18:18:42 #link https://wiki.openstack.org/wiki/TroveDBInstanceLogOperation 18:19:23 denis_makogon: ? 18:19:35 so in general, i think that we need to do this 18:20:35 yeah that sounds like a good idea 18:20:35 id like to get your opinions (denis is not here today) 18:20:42 not in the meeting of course 18:20:50 but on the wiki / mailing list / etc.. 18:20:58 it would be great to get the logs out of the guest for debugging purposes and such 18:21:02 I agree, I think this is a generally good idea. 18:21:08 looks good to me 18:21:09 idea++ 18:21:14 +1 18:21:18 ill be replying to the mailing list, and adding a title to his email, so watch for that today 18:21:20 i +1 it 18:21:24 ok great 18:21:27 nice 18:21:28 as long as they are only stored on the guest 18:21:40 Not sure I'm convinced about the implementation that that page is hinting at, though. 18:21:42 imsplitbit: they are going to be streamed only to the customer directly via the guest 18:21:44 yes no need to pull them up to one large central system 18:21:48 so are we strreaming them down via API? 18:21:54 imsplitbit: it uses swift I think 18:21:58 right, I +1 that hub_cap 18:21:59 customer get sa user/password to rabbitmq, and is able to read the logs from rabbit 18:22:01 swift i'm ok with 18:22:04 robertmyers: that too would be ok 18:22:07 vipul: i think first pass is just switf 18:22:18 I just don't want to get into the business of central log aggregation as a service 18:22:19 vipul: i think second pass could offer X number of last lines via api 18:22:24 customer gets a "one time use" ssh session to get th logs ;) 18:22:34 hub_cap: fail 18:22:36 are we concerned with sensitive things in the log files... 18:22:36 hub_cap: bite your tongue 18:22:37 can someone detail the API calls that would exist? Its not clear from the wiki 18:22:38 hub_cap: Great idea 18:22:40 HAH 18:22:52 * konetzed slaps hub_cap 18:23:03 I can see there is a GET to basically move a log file to swift 18:23:05 demorris: hes starting with the swift stuff, so "move/delete" log file in swift 18:23:20 what about a list of what logs are available to get? 18:23:25 hes not doing the "tail" for a customer 18:23:29 demorris +1 18:23:33 demorris: i think u should know the list of those right? 18:23:41 not for all datastores 18:23:43 do we need a "list" of log files avail for mysql? 18:23:45 Eh, let's not get into enumerating info swift has that the user could get for themselves. 18:23:47 slow query log 18:23:50 mysql has like 9 log files 18:23:51 you should be able to query what logs are available 18:23:51 vipul: i dont think we need to worry about that as much, this is a customers instance if they have sensitive things in their logs they also have access to get them from the db 18:23:51 probably need list/save 18:23:55 hub_cap: Will users be able to specify the swift file path? 18:24:00 one provider may expose slow query, another may not 18:24:05 * hub_cap shrugs grapex 18:24:13 kevinconway: ... 18:24:16 9? 18:24:18 hub_cap: Well if not, demorris's suggestion makes more sense 18:24:20 demorris: so for this, list seems sensible 18:24:21 i still think slow query log should go in the db for mysql 18:24:26 but then again 18:24:30 konetzed: Yea i guess so.. 18:24:31 imsplitbit: 10? 18:24:34 imsplitbit: fine, 5. http://dev.mysql.com/doc/refman/5.1/en/server-logs.html 18:24:40 imsplitbit: its written in java, 9 files 18:24:43 also, what happens if I move a log to swift multiple times 18:24:43 demorris: if they can list log files, should trove also allow them to download them through the trove API and not via swift? 18:24:45 adding on to grapex's question: or specify the container to store the logs files in? 18:24:54 does it overwrite the existing? Create a new entry in swift? 18:25:04 kevinconway: i dont think its fair to count binlogs there either, so, 4 ;) 18:25:05 but for debugging purposes you really only need access to the general log and slow query log 18:25:09 grapex: some of those log payloads are going to be big 18:25:12 grapex: not sure about that 18:25:13 grapex: i think you can only get x number lines back throught he api 18:25:14 rather, the end user only needs those 18:25:17 seems like swift would be the right place for them 18:25:19 grapex: like the last 100 or so 18:25:22 kevinconway: yeah, I don't think we should support downloading swift objects via Trove 18:25:32 demorris: So in that case, lets not let people enumerate the swift files either. 18:25:54 Sounds like this could be a fairly simple API- like we don't want to store that much info in the database 18:26:15 As in, we won't have that any metadata for each log we back up. If we do, we need to enumerate that stuff. 18:26:43 grapex: agreed. Let's just support the copy to swift operation. To read / download the logfiles then they would have to use the swiftclient. 18:27:27 SlickNik: Cool. vipul / hub_cap, thoughts? 18:28:12 One issue is there *can* be a subtle delay when you try to get files you just uploaded from Swift 18:28:12 grapex: agreed.. i think just a list what's available.. and save operation 18:28:19 and they can look in swift to find what they need 18:28:28 we don't even need a delete.. 18:28:35 it shouldn't be tracked as a resource by Trove 18:29:26 so what if I request a log multiple times? Is the behavior that it overwrites the existing file? 18:29:43 demorris: no, it changes the timestamp 18:29:44 demorris: aye 18:29:48 demorris: If you specify it to, yes 18:29:51 vipul: not sure about not having a delete, why would we not provide the ability to remove the log? 18:29:58 i think we all have different opinions here heh 18:30:08 robertmyers: +1 18:30:12 we provide the ability to delete backups that are stored in swift 18:30:27 demorris: we should only provide a way to get at the logs.. not manage them in Trove 18:30:29 demorris: but those are our resources 18:30:35 logs are the users 18:30:36 That's because we need the backups to restore from 18:30:42 demorris: That's because we track backups as trove resources. 18:30:45 backups are the users 18:30:48 its their data not ours 18:31:14 demorris: technically, but with out our api it is worthless 18:31:49 not really though 18:32:10 no for reals 18:32:12 basically, they have to build an exact image of a trove host 18:32:38 same mysql and everything to work with xtrabackup 18:32:56 my point is that if we are going to allow a customer to create something in their swift account, we should provide the ability to delete it as well 18:33:09 they have that ability 18:33:11 in swift 18:33:14 demorris: Interesting premise. 18:33:20 imsplitbit: +1 18:33:23 seems like a duplication of work 18:33:29 imsplitbit: +1 18:33:47 then why don't we do that for backups? 18:33:56 I can see how it would be a pain to have to know that a file Trove named some weird GUID was for a backup that was deleted. 18:33:59 the only point of the logs api is to put it in swift 18:34:05 And not a backup that is needed. 18:34:16 demorris: I think the log api would be different 18:34:17 the backups are different use case 18:34:32 we just store them in the same place 18:34:45 the customer only interfaces with trove for backups 18:34:56 to create/delete/restore 18:35:17 logs they will need to go to swift to read the log 18:35:21 demorris: backups are a special snowflake since we need them exact same bits for restore. 18:35:46 demorris: We don't need to use he logs for anything in the future, so we don't need to manage them any longer. 18:36:23 demorris: The difference is we don't manage that data- it's just a text file 18:36:42 Backups are more complex, so we have to manage it for users to give them a decent experience 18:38:57 okay, so thats fair 18:39:20 ok so um, mailing list? 18:39:25 yes 18:39:30 yep 18:39:37 do it 18:39:39 I thought we all agreed 18:40:01 #topic reviews on the meeting agenda 18:40:04 i think this is a great first rev here for log integration 18:40:40 is this for general review? 18:40:49 reviews? 18:41:12 id prefer us to _not_ put reviews on the meeting agend 18:41:16 *agenda 18:41:19 hub_cap: I like it 18:41:25 got it 18:41:28 ok cool, lets not do this anymore :) 18:41:46 but how else can we beg for +2s? 18:41:51 LOL 18:42:01 paypal 18:42:07 vipul: ++ 18:42:10 lol 18:42:12 vipul 18:42:16 i think it could be fair to put some review if its part of a bigger conversation 18:42:17 Maybe it should be allowed if it you're not posting your own review. 18:42:24 have you seen gittip? 18:42:33 but not the whole "open discussion" "look at my shiz" 18:42:36 where did that conversation about ranking reviews by oldest first go? 18:42:43 hub_cap +1 18:42:44 yes sign up for gittip and get some $ on the side 18:43:14 I'm also okay if there's been a review that's fixing a broken gate or something needs urgent attention. 18:43:46 so… are we out of things to talk about then? 18:44:41 sorry, was afk 18:44:44 #topic next meetings 18:44:47 so 18:44:53 no longer at noon??? 18:44:57 yes! 18:44:59 +10000000000000000000000 18:45:02 +1 18:45:06 imsplitbit: shaddup 18:45:08 imsplitbit: +1 18:45:30 I vote for meetings on Christmas and New Years 18:45:45 I won't attend, but I think you all should :D 18:45:50 ha 18:46:04 so we have 2x meetings during holidays 18:46:10 not a huge fan of noon meetings but i don't mind them 18:46:11 o/ 18:46:28 hi cweid 18:46:56 hub_cap: quick end the meeting 18:47:01 :) 18:47:02 Wait 18:47:10 well hold up. are we saying we should skip 2x meetings? 18:47:13 Are we considering the next two meetings? 18:47:23 skip next two weeks 18:47:26 I don't care, I'm out for 3 weeks 18:47:27 the next two wednesdays are crimbo and new years 18:47:36 I'll be out for the next two weeks anyway 18:47:37 yea most people won't be around 18:47:55 im ok w it, i feel like our last meetings have been slower due to the holidays 18:48:30 I'm okay with skipping them as well. 18:48:40 +1 skip 18:49:00 We can bring things up in the channel, in case anything comes up. 18:49:28 okey dokie 18:49:33 #topic general discussion 18:49:57 can we just eliminate time zones? 18:49:57 just an updated on usage events... 18:50:27 juice: hit me 18:50:36 the issue was a confusion across the class hierarchy in instance tasks and its parent SimpleInstance 18:50:50 As you all know we have a lots of classes with The name status 18:50:56 well they got mixed up 18:51:00 nice 18:51:04 sometimes using one sometimes the other 18:51:16 so I went through BuiltInstance and wrote a unit tests 18:51:22 made it consistent 18:51:39 juice: Which two status classes were getting mixed up? 18:51:53 InstanceServiceStatus, ServiceStatus and sometimes a String 18:52:02 sometimes a lowercase string comparision 18:52:13 to a Status class 18:53:08 so I'm a little concerned because as you know there is a lot of logic surrounding status 18:53:41 juice: They all have their own purpose... I guess I'll have to see on the pull request, I'm sure its good stuff. 18:54:36 grapex - the challenge is knowing which one to use where 18:54:39 and when 18:54:48 use them all just to be sure 18:55:26 kevinconway - that's what I did, I just created a new class called TheRealStatus and changed all the code to use it instead 18:55:40 Not sure if that's a joke... 18:55:42 it catches any exceptions to and just logs them and keeps trucking 18:55:57 InstanceServiceStatus is a wrapper around the database object represented by ServiceStatus. I think the problem is, ServiceStatus was too thin to really need a wrapper. 18:55:58 well it's supposed to be an aggregate or gestalt status at least 18:56:04 so tests are guaranteed to pass now 18:56:06 Or maybe decorator is the right term 18:56:45 the goal was to keep from getting nova and trove statuses getting confused 18:56:49 correct instance service status had the dbinstance + service_status if my memory serves me correct 18:56:51 juice: i hope to see variables named the_real_status in your code 18:57:04 for realz 18:57:12 new_the_real_status_for_real 18:57:22 juice: How about StatusStatus? 18:57:24 not allowed to implement a please_stand_up method 18:57:45 the odd thing is that instance_service_status is almost always used within *Instance which also has DBInstance 18:57:53 so it seems a bit redundant 18:58:09 I didn't go to the extent of refactoring any classes 18:58:15 see i was about to ask that 18:58:45 I'll have a review up today for you guys to check out. 18:58:57 juice: cool 18:59:05 i need to review it myself to see all that has been changed 18:59:06 Thanks juice! 18:59:31 and un doubtedly a merge or two to do since I have been working on this since Jesus' birth 18:59:37 speaking of which... 18:59:43 #endmeeting 18:59:45 ;) 18:59:52 burn 18:59:53 merry christmas everyone enjoy your holidays 19:00:07 hub_cap :) 19:00:35 looks like it didn't actually end 19:00:42 merry holidays 19:00:54 oh yay!!! I get to talk more 19:01:01 see yall in a few wks 19:01:02 you can't shut me down hub_cap! 19:01:02 happy days of less work due to winter seasons 19:01:22 that's the spirit kevinconway 19:01:28 don't forget the awesome sales too 21:52:11 t 22:14:59 Hi, Is the meeting regarding Neutron 3rd party testing is taking place? 14:00:35 good morning/afternoon/evening 14:00:51 markwash: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 14:01:00 oh no! 14:01:05 endmeeting 14:01:08 #endmeeting