18:00:09 #startmeeting trove 18:00:10 Meeting started Wed Jul 22 18:00:09 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:14 The meeting name has been set to 'trove' 18:00:38 o/ 18:00:50 Hey there. 18:01:04 Giving folks a couple of minutes to trickle in. 18:01:16 meeting agenda at: 18:01:23 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:01:41 o/ 18:01:44 ~\o/~ 18:01:52 ☻/ 18:01:53 o/ 18:02:07 o/ 18:02:17 #topic Trove pulse update 18:02:18 o/ 18:02:23 #link https://etherpad.openstack.org/p/trove-pulse-update 18:03:15 o/ 18:03:41 Review velocity seems back up again — which is good to see. :) 18:05:55 o/ 18:06:13 Other questions on this? 18:06:13 o/ 18:06:35 If not, let's move on. 18:07:02 #topic mysql manager refactor 18:07:17 #link https://review.openstack.org/#/c/204279/ 18:07:33 atomic77: around? 18:07:35 hi everybody 18:07:41 I wanted to do a quick checkpoint with the community on the mysql manager refactor 18:07:59 because i know there are a few things in dev right now like percona cluster that might be affected, and there were some important details that were neglected in the spec 18:08:28 The link above is a WIP patchset i put up last night which still needs work, but is passing most unit and int tests 18:08:43 o/ 18:09:08 the important part that wasn't really specified is that the service classes like MySqlAppStatus which were pulled in as import statements are now class properties that are injected 18:09:31 * SlickNik gives the review a quick look over 18:09:36 o/ 18:09:48 you can see how this works in the 'new' manager_base.py file in the patchset and the new 'stub' manager.py for any of the datastores provided (eg percona, mysql and mariadb) 18:10:52 atomic77: side question about this... did you ever try and boot a percona instance? 18:11:36 with this refactored code, not yet 18:12:05 ok could you try and do that sometime and let me know if it fails for weird reasons... 18:12:46 i've found that percona has been not creating the os_admin user and causing issues 18:12:51 but the refactor was intended to lay the ground work for fixes specific to the datastores, not optimize for them 18:13:02 have not been able to figure out why its happening yet tho 18:13:16 atomic77: Looks great at a first glance! 18:13:26 yeah just curious if there is a chance it works 18:13:33 ^atomic77: Just wondering. Could not those utility classes be possibly passed to the init by the concrete class? 18:13:44 cp16net, it's somethign worth trying though 18:14:13 atomic77: Will review it a bit more in depth over the next couple of days. 18:14:14 yeah i'd appreciate some feedback on that case since its what i've been working through 18:15:08 pmalik, you mean as part of the constructor? 18:15:15 yes 18:15:31 ^atomic77 18:15:32 i tried as much as possible to leave the original logic and code intact 18:15:56 but if there are some improvements and optimizations we can all agree make sense, then why not do them 18:16:44 I don't know. Would it be a problem? Because the concrete class should know what it needs and that way we would not require any new config options. 18:16:49 ^atomic77 18:17:13 just an opinion... 18:18:30 pmalik, it makes sense. maybe a separate patchset to follow up the refactor to optimize some of this stuff? 18:19:18 since so much code is going to be moving, wanted to get this on people's radar for when the merging fun begins :) 18:19:25 ^atomic77 Possibly. I don't know what others think. :-) 18:20:08 atomic77: i think you are on a good path forward there 18:20:49 pmalik / atomic77: I think either approach is okay (overriding __init__ or passing the values in to the base class). 18:21:12 ok, just wanted to make sure there were no serious concerns since this was not really discussed in the bp 18:22:11 atomic77: not a problem, would be nice if you could go update the spec with this new info when you have a moment. 18:23:11 SlickNik, i.e. submit a new patchset for the spec itself? 18:23:32 atomic77: very often something comes up during implementation that hasn't been called out explicitly in the spec — shouldn't be an issue as long as we think it's the right path forward. 18:23:55 atomic77 yes, i believe he is asking you to update the spec 18:23:56 atomic77: yes that way the spec is in sync as well. 18:24:10 (y) 18:24:38 i had thought it might make sense to do a metaclass to import the datastore manager 18:25:08 ok, sounds good. 18:25:22 it might make things a little cleaner but could also make things a bit more confusing if you dont understand how it works 18:26:08 cp16net, right, i didn't want to introduce complexity for the sake of complexity, but in this case we really do need some way to decouple these classes 18:26:25 cp16net: did you just volunteer for a spike / poc? 18:26:33 did i? 18:26:35 :-P 18:26:47 That's what it sounded like from here :P 18:27:09 i could but i dunno when i will have time for that right now 18:27:52 unless i find its a nessescity for clustering 18:28:15 cp16net: yup — understood. 18:28:24 Anything else for atomic77? 18:28:37 i dont think it is but it's not outside of the posibilities right now... 18:29:42 Okay. Moving on... 18:29:51 #topic Open discussion 18:30:26 Anything for open discussion? 18:31:11 I have a reminder that the Trove Liberty mid-cycle meetup is in just over a month's time. 18:31:23 (and also Trove day.) 18:32:07 next week is liberty 2 already... 18:33:03 Please register for the mid-cycle sprint here (if you haven't done so already): https://www.eventbrite.com/e/trove-mid-cycle-sprint-liberty-tickets-17600134476 18:33:25 cp16net: Yup, liberty-2 cut is next week. 18:33:59 reminder link 18:34:02 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 18:34:54 cp16net: thanks! 18:35:05 Anything else for open discussion? 18:35:43 Okay, we can end early and folks can have some of their time back. 18:35:47 #endmeeting