18:00:07 <cp16net> #startmeeting trove
18:00:08 <openstack> Meeting started Wed Jul 29 18:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is cp16net. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:12 <openstack> The meeting name has been set to 'trove'
18:01:05 <vkmc> o/
18:01:10 <georgelorch> o/
18:01:15 <sushilkm> o/
18:01:24 <cp16net> o/
18:01:37 <ashleighfarnham> \o/
18:01:46 <atomic77> O/
18:02:26 <mvandijk_> 0/
18:02:32 <cp16net> so slicknik is out for the rest of the week so i'll be running
18:02:38 <cp16net> meeting agenda at
18:02:45 <cp16net> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:02:52 <cp16net> have a few topics to cover
18:02:53 <peterstac> o/
18:03:02 <cp16net> #topic Trove pulse update
18:03:10 <cp16net> #link https://etherpad.openstack.org/p/trove-pulse-update
18:04:18 <vgnbkr> o/
18:04:45 <cp16net> looks like the reviews are down a little but still steady
18:05:24 <cp16net> any questions on this?
18:06:22 <cp16net> #topic voting for Tokyo Summit presentations (cp16net)
18:06:29 <sushilkm> reviews look steady but very few merges
18:07:02 <cp16net> we have quite a few presentations proposed for the tokyo summit
18:07:29 <cp16net> i think i listed them all on the meeting page
18:08:05 <cp16net> get out the vote for the ones you would like to see
18:08:19 <cp16net> there are about 12 that i found
18:08:32 * vkmc adding Table for Two: Trove and a Guest by abramley, vkmc and pmackinn to the list
18:08:33 <vkmc> :)
18:09:21 <cp16net> vkmc: nice
18:09:59 <cp16net> the search seemed a bit difficult so i might have missed some
18:10:23 <cp16net> any other comments?
18:10:53 <vkmc> oh yes, there are so many great proposals about Trove :)
18:11:12 <cp16net> for sure! looking forward to them
18:11:23 <cp16net> alright moving on
18:11:44 <cp16net> #topic Datastore registration spec open questions (cp16net)
18:12:38 <cp16net> so there was a discussion in the channel between _amrith_ slicknik sushilkm and cp16net about this
18:13:37 <cp16net> so there was conflict on how we should structure the mgmt api to include updating the datastore and versions
18:14:14 <cp16net> in the meeting notes i put my thoughts
18:14:40 <cp16net> and slicknik added his thoughts sine he wont be here to talk about it
18:14:51 <cp16net> _amrith_: around?
18:15:30 <vkmc> cp16net, remember when the first discussion took place?
18:15:33 <vkmc> so I look for the logs
18:16:10 <cp16net> sushilkm: do you remember?
18:16:30 <cp16net> i think it was mon or fri of this last week?
18:16:45 <vkmc> no hurries, I can look for those after the meeting
18:17:04 <vkmc> have been away last week, seems there has been a lot going on :D
18:17:07 <sushilkm> it was 22-Jul night
18:17:17 <vkmc> thanks sushilkm
18:17:33 <cp16net> so the current proposal was to simplify the api as slicknik suggested
18:18:28 <cp16net> where the api will handle the logic of creating a new datastore if it doesnt already exist and create the version
18:18:47 <sushilkm> if someone wants to view logs of discussion, please refer http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2015-07-23.log.html
18:19:12 <vkmc> sushilkm++
18:19:29 <sushilkm> I am in consent/favor of 3rd and 4th point from SlickNik
18:20:03 <cp16net> #link http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2015-07-23.log.html
18:20:27 <sushilkm> even cp16net's 2nd point seems good
18:21:52 <sushilkm> the comments are listed on meeting agenda from cp16net and SlickNik
18:21:57 <cp16net> _amrith_: mentioned to make the api adhere to the database models on the backend
18:22:11 <vkmc> unless the datastore-version endpoint has way too many operations, I'd lean towards having an unified API
18:22:13 <cp16net> and be simple crud operations
18:22:29 <vkmc> so we keep things simple
18:23:54 <cp16net> after lots of thought on this i'm think there needs to be a simplified way to update the version info
18:24:09 <sushilkm> the difference is just double, if we keep go with datastore-version-only API the number of APIs needed to be added gets half
18:24:10 <cp16net> *usually* we update the image id
18:24:35 <cp16net> not much else needs updating from the datastore or version
18:27:58 <vkmc> we should leave the comments here https://review.openstack.org/#/c/188072/19
18:27:59 <cp16net> i dont think making the client thicker to manage multiple calls is a good solution
18:28:29 <edmondk> I am trying to get caught up are we basically saying either we have the datastore and version as one POST together vs. having the datastore and version as separate resources?
18:28:54 <cp16net> vkmc: thats a good idea since the other partys are not here to talk about this.
18:29:10 <cp16net> #link https://review.openstack.org/#/c/188072
18:29:31 <vkmc> :)
18:29:44 <cp16net> edmondk: essentially yes that is the highlevel debate
18:30:06 <sushilkm> edmondk, there would be one POST for datastore-version, and while creating datastore-version it wud check if datastore does not exists same would be created
18:30:07 <edmondk> I would think having them together makes more sense because they will always be coupled together
18:30:16 <sushilkm> also suggested in https://review.openstack.org/#/c/188072/19//COMMIT_MSG
18:30:20 <vkmc> edmondk++
18:30:34 <vkmc> feels more natural IMO
18:30:45 <vkmc> although I'd like to hear the counter arguments to that
18:31:12 <cp16net> yeah same here vkmc
18:31:41 <cp16net> that night we were talking about it i was inbetween if it was a good idea or not
18:31:46 <edmondk> I would think the payload would be like datastore : { type: mysql, version: 5.5 }
18:31:50 <edmondk> you would always put them together
18:32:03 <edmondk> then you can do PUT { type: mysql, version: 5.6 }
18:32:05 <cp16net> one side of me said i wanted it together
18:32:10 <edmondk> to update version
18:32:26 <cp16net> the other side said its not really restful
18:32:49 <edmondk> why is it not RESTful?
18:33:04 <edmondk> we have a resource datastore
18:33:08 <cp16net> because its not repersenting the data underneath
18:33:10 <edmondk> which has a type and a version coupled together
18:33:14 <vkmc> having it separately may be error prone as well... if you forgot to update one of them
18:33:44 <cp16net> yeah it leads to what we have today in the manage cmd
18:34:29 <cp16net> the workflow of add datastore
18:34:33 <cp16net> add version
18:34:46 <cp16net> update datastore version default
18:35:03 <sushilkm> the current implementation needs to executed 3 calls to register an image-id
18:36:25 <edmondk> that is odd
18:36:47 <cp16net> ok lets put these ideas into the review
18:37:11 <cp16net> shall we move on?
18:37:29 <vkmc> yeah its not very straightforward, I always assumed there was a reason behind it heh
18:38:18 <cp16net> #action cp16net vkmc sushilkm edmondk add comments to the datastore registration spec review
18:38:18 <vkmc> yeah, let's keep with this in the reviews for that spec
18:38:28 <cp16net> :-)
18:38:38 <cp16net> #topic Open discussion
18:39:08 <cp16net> anything for open discussion?
18:39:58 <cp16net> liberty-2 was cut yesterday 7/28
18:40:00 <cp16net> #link https://launchpad.net/trove/liberty/liberty-2
18:40:30 <vkmc> I was going to ask about it :)
18:40:33 <vkmc> cooooooool
18:41:07 <cp16net> yeah there are some good patches that got in
18:41:23 <cp16net> so in a months time is liberty-3
18:41:47 <cp16net> and 1 week of that nothing much will get done since we are at the midcycle
18:41:52 <cp16net> speaking of midcycle
18:42:10 <cp16net> 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:42:38 <cp16net> alright anything else?
18:43:22 <cp16net> quiet around here today...
18:44:07 <cp16net> alright everyone have a great day
18:44:18 <cp16net> #endmeeting