17:59:37 #startmeeting trove 17:59:38 Meeting started Wed Aug 5 17:59:37 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:41 The meeting name has been set to 'trove' 17:59:58 giving folks a couple of minutes to trickle in. 18:00:00 hi all 18:00:11 hi 18:00:18 hello everyone 18:00:22 \-=O=-/ 18:00:35 o/ 18:00:38 ~o~ 18:00:42 o/ 18:01:21 o/ 18:01:36 o/ 18:01:44 meeting agenda at: 18:01:46 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:02:25 #topic Trove pulse update 18:02:31 o/ 18:02:35 ☺/ 18:02:35 #link https://etherpad.openstack.org/p/trove-pulse-update 18:02:39 p/ 18:03:33 ~140 reviews this week. 18:03:57 fairly good standard pace. 18:04:18 We cut Liberty-2 last week, so we're now in Liberty-3. 18:04:29 Good time to step up the pace on reviews. :) 18:05:23 sounds like a plan 18:06:06 i figured out how to pull the stats last week SlickNik :-P 18:06:18 Feature freeze will be end of this month (week of Aug 31st) so we need to land BPs for liberty by then. 18:06:30 The schedule is here: 18:06:32 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 18:06:39 cp16net: awesome. :) 18:06:41 yeah we have quite a few in progress 18:07:19 first week of September, w00t! 18:08:16 Yup, I'm going to start using the "starred changes" to prioritize reviews for BPs that we should land in Liberty. 18:08:38 So keep an eye out on the custom dashboard at: http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_trove.html 18:09:21 vkmc: yeah, time flies. It's August already! 18:09:40 yeah >.< 18:09:50 sounds good 18:10:17 i sorta wish i could see your stars separate from my own in the dashboard 18:10:46 Yeah, unfortunately you have to do a diff. 18:10:54 would others want that? 18:12:35 Can add a different section to the custom dash if folks prefer that. 18:13:04 Any other questions regarding reviews, liberty schedule, etc? 18:13:18 yeah thats what i was thinking 18:13:23 not from me 18:13:48 Okay, let's move on. 18:13:56 do we have a priority list for l3? from the specs currently in the review queue 18:15:02 vkmc: Not yet — I'm planning to put one together on an etherpad, and we can work off of that. 18:15:09 sounds good 18:15:21 what about off the prio in launchpad? 18:15:44 we have 11 open specs 18:16:13 I'm seeing 18 here: https://launchpad.net/trove/+milestone/liberty-3 18:16:33 yeah thats what i see as well 18:16:49 maybe some specs are approved and 11 are not 18:17:01 oops infact 10 i checked open reviews on trove-specs 18:17:30 yeah we need to get through those 18:17:30 cp16net: The launchpad priorities only have high, med, low. I was thinking something more like a list from high to low, so you can just walk down it (say for reviews). 18:17:59 SlickNik: ok i gotcha 18:19:08 SlickNik, can https://blueprints.launchpad.net/trove/+spec/mysql-manager-refactor go into L3? 18:19:09 #action SlickNik come up with a prioritized list of BPs (and corresponding reviews) that need to be merged for liberty. 18:19:52 pmackinn: yes! I'm surprised that it's not already in (probably an oversight). 18:20:13 updated 18:20:18 SlickNik, awesome 18:20:42 Anything else? 18:21:07 . 18:21:11 Okay, let's move on. 18:21:30 #topic Datastore registration spec open questions 18:21:38 #link https://review.openstack.org/188072 18:21:56 sushilkm: all yours — go for it. 18:22:08 yes ... we discussed this topic last week, but since both SlickNik and _amrith_ were not present, there was not reached a conclusion 18:22:33 which is why i brought it forward to have a conclusion and get it moving ahead 18:23:12 so like it was discussed last week, question is 18:23:16 Should the api be simple CRUD operations on each object? (i.e. CRUD on datastores and versions separate) or make the API simplified where we really only care about the version when we update the image on an existing version or create a new version 18:24:03 I'm fine with the unified simple API — i.e. the way the spec is written. 18:24:16 Had a couple of minor comments, but it looks like you fixed that last night. 18:24:32 I'm up for the unified simple API as well 18:24:39 yep the minor comment about response code is fixed, now it remains to answer of this question only 18:25:16 * cp16net refreshes myself on whats there now 18:25:21 so looks like i have 2 +2s .... 18:25:43 * sushilkm waiting for others to pour in the thoughts 18:27:12 sushilkm: Since amrith had some concerns were you able to follow up with him to address / alleviate some of that? 18:27:19 one minor thing i just looked at... 18:27:36 payload "packages": "mysql" 18:27:48 nopes i was not able to get in touch with amrith since morning 18:27:55 should we make that a list? "packages": ["mysql"] 18:27:57 ? 18:28:27 or just a comma list "packages": "mysql, common-mysql" 18:28:31 blah blah blah 18:28:37 is it currently a list? 18:28:40 nope 18:28:42 i did not get that, do you mean that we can support multiple packages 18:28:55 yes 18:28:57 this parameter is currently a text, and not a list 18:28:58 yeah but its a comma string in the db 18:29:03 that would be great 18:29:08 I don't think it makes sense now 18:29:12 maybe in a follow up patch 18:29:14 cos its not trivial 18:29:46 yeah but its part of the payload of the api 18:29:53 vkmc: user might want to install mysql, xtrabackup, blah, blah 18:29:56 we should avoid changing that 18:30:02 bhaskarduvvuri: yup 18:30:19 dumb question...what is packages for if the image has been built with a DB package? what is it specifying? 18:30:24 cp16net / vkmc: Maybe clean up the API payload but keep the backend implementation the same. 18:30:34 SlickNik, agree 18:30:40 pmackinn: if you use a base image across 18:30:56 and need extra packages installed 18:31:11 pmackinn: There is support in the trove guest to actually install these packages in case your image doesn't already have them baked in. 18:31:21 but i know not all deployments have access to install components 18:31:42 so this doesnt work in all cases but per deployment 18:31:53 pmackinn: If your guest image already has the necessary packages, it's a no-op. 18:31:56 but no API for repo location 18:32:12 SlickNik, not sop sure about that :-) 18:32:15 so sure 18:32:18 SlickNik: yeah if the api payloads are specified that with a list i think thats is fine 18:32:26 i dont care how the backend does it 18:32:57 pmackinn: Yeah, the API repo location would need to be configured out of band (in the image). 18:33:12 yep 18:33:38 pmackinn: FWIW No one I know actually uses this feature — almost everyone deploying trove bakes all the dependencies into the guest image. 18:34:13 so, is the deal to get packages in the form of list or a simple text 18:35:00 added a comment on the packages 18:35:11 true 18:35:18 SlickNik: But i believe it is a useful feature 18:35:43 ok, cool 18:35:44 bhaskarduvvuri: Yes — not arguing that. :) 18:35:46 i wud make ammends 18:35:58 any more suggestions from anyone are welcome 18:35:59 yeah even our tests now bake everything in 18:36:00 would it make sense to make it optional? 18:36:20 vkmc: i think it should be. 18:36:21 considering most users use prebaked images 18:36:35 vkmc: I believe it is optional (should be, but need to double check). 18:36:45 it doesnt need a value in the db 18:36:56 Oh, maybe you mean optional in the API? 18:37:03 Yes, that's a good idea. 18:37:07 our test inactive_version has no packages 18:37:11 yup 18:37:12 cool 18:37:12 It's optional in the db/backend. 18:37:42 +1 18:37:49 Agreed that it should be optional in the API as well. 18:38:14 +1 18:38:29 I agree 18:39:31 consensus \o/ 18:39:36 sushilkm: Got enough info for a path forward here? 18:39:45 yep sure 18:39:45 If so, let's move on. 18:39:52 #topic Open Discussion 18:40:38 SlickNik, requesting a security session at the mid-cycle please 18:40:40 Anyone have anything for Open Discussion? 18:41:01 pmackinn: roger that — I think we have an open slot. 18:41:26 SlickNik, ty 18:41:37 I think it will be useful. 18:41:37 I was working on creating a MariaDB basic driver based on the MySQL refactor atomic77 did 18:41:50 do you guys think it makes sense to submit an spec for l-3 and make it happen? 18:42:00 ahh speaking midcycle discussions i brought up something last week as well. 18:42:26 #action SlickNik update mid-cycle agenda with a session on Trove Security. 18:42:40 where is the midcycle schedule link? 18:42:53 vkmc: Depending on how big the set of changes needed are, I think it might still be very doable for l-3. 18:43:16 cp16net: linked off of https://wiki.openstack.org/wiki/Sprints 18:43:23 I can submit the patches and see if we can make it on time 18:43:28 vkmc, did you run into any problems? 18:43:38 SlickNik, we'd need the mysql refactor to go in 18:43:39 atomic77, nope, it works like a charm :) 18:43:49 vkmc: I think mariadb support is super valuable. 18:44:01 atomic77, \o/ 18:44:02 (cp16net) We show talk about how to make some magic for setting strategies on versions and not just datastores. I.e. mysql 5.5 strategies might not all work for 5.6 or the next version of mysql. Redis could be similar between 2.8 and 3.0. 18:44:02 cool, because everything was supposed to work "in theory" but practice is a whole other thing :) 18:44:09 i added that last week 18:44:16 SlickNik, I think so too... more because its the default for distros different than Ubuntu 18:44:27 vkmc ++ 18:44:54 maybe we won't be able to add support to GTID based replication (Maria implements it differently than MySQL) 18:45:03 pmackinn: It's on my priority list for l3, so definitely hoping to get it in. 18:45:10 but at least our users will be able to launch mariadb instances 18:45:40 vkmc: I'd suggest adding support for MariaDB instances and creation in L and then working on replication for it in M. 18:45:56 vkmc: from what i know GTID in MariaDB is _quite_ different. 18:45:59 SlickNik ++ 18:46:10 yeah, totally different 18:46:23 SlickNik, orthogonally, i'm getting closer on Fedora+redstack and it'd be great to have the mariadb support 18:47:17 nice 18:47:24 pmackinn: That's super cool! I think I need a demo once you have that up and going :) 18:47:29 * cp16net excited! 18:47:47 :D 18:48:18 that sounds awesome pmackinn 18:48:54 On a somewhat different note — I notice a new face (alias?) in here. 18:49:16 bhaskarduvvuri: hi! welcome. 18:49:18 yeah, me too 18:49:22 bhaskarduvvuri, o/ 18:49:37 bhaskarduvvuri, o/ 18:49:37 Hi Guys 18:49:53 bhaskarduvvuri: welcome 18:50:01 welcome 18:50:34 thank you sushilkm, cp16net, vkmc, pmackinn, SlickNik 18:51:30 Alright, any other questions / items for open discussion? 18:52:15 any one looked at http://www.aerospike.com/ ? 18:52:42 thought i might have a go as an experimental 18:52:57 Huh no — my first time seeing it — looks interesting. 18:53:15 stumbled on them at oscon 2 weeks ago 18:53:28 those stats mentioned on homepage luks stunning 18:54:23 looks very good 18:54:41 kewl 18:54:51 packages by them but none in our distros afaict 18:55:08 i'll kick the tires 18:55:32 pmackinn: Sounds good. Let us know how it goes! 18:55:38 SlickNik: if we have room i think we should talk at the midcycle about how to support versions 18:55:39 yep 18:55:59 with different strategies 18:56:00 cp16net: yes, I agree. 18:56:52 +1 18:57:02 We have an issue today, where strategies are associated with the datastore name (not version) and there are plenty of valid scenarios when you'd want to use a different strategy for a different version. 18:57:18 +1 18:57:48 tricky indeed 18:58:09 yeah, the case is valid and needs to be give a thought 18:58:19 #action SlickNik update the mid-cycle agenda with discussion around strategies per datastore version. 18:58:19 sounds like a BP for M release :) 18:58:43 sushilkm: Yeah, seems like we need to rethink the design here a little bit. 18:59:12 Okay, anything else before we call it a meeting? 18:59:22 any update on sql server bp or did we scare them off? 18:59:41 pmackinn: I didn't hear back :( 18:59:59 do we have any plans on implementing oracle db 19:00:04 SlickNik: fixing the gate? 19:00:06 :-P 19:00:32 cp16net / bhaskarduvvuri: Let's take the discussion to #openstack-trove. 19:00:32 huh, oracle db will require some licensing discussion 19:00:42 We're at the top of the hour. 19:00:46 sure 19:00:47 #endmeeting