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