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