18:00:01 <cp16net> #startmeeting trove
18:00:01 <openstack> Meeting started Wed Nov 18 18:00:01 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:04 <openstack> The meeting name has been set to 'trove'
18:00:08 <SlickNik> o/
18:00:10 <cp16net> #topic rollcall
18:00:24 <ashleighfarnham> hi!
18:00:24 <cp16net> howdy everyone
18:00:32 <dougshelley66> o/
18:01:47 <pmalik_> */
18:02:13 <atomic77> O/
18:02:17 <cp16net> hope everyone is having a good week
18:03:39 <dougshelley66> well, it is a week
18:03:48 <cp16net> cant deny that...
18:03:50 <vkmc> o/
18:03:51 <cp16net> :)
18:04:00 <vkmc> tellesnobrega, ping
18:04:07 <amrith> ./
18:04:11 <peterstac-m> o/
18:04:35 <cp16net> #topic trove pulse update
18:04:40 <cp16net> #link https://etherpad.openstack.org/p/trove-pulse-update
18:04:48 <cp16net> #link http://bit.ly/1VQyg00
18:05:20 <cp16net> we are ticking up on the reviews
18:05:46 <cp16net> we got a bit of stuff merged
18:06:13 <cp16net> the changes are still growing tho
18:07:19 <cp16net> we've gotten a bit of the specs approved which is great
18:08:30 <cp16net> thanks to everyone keeping up on reviews
18:09:58 <cp16net> any other comments?
18:10:18 <amrith> ./
18:10:35 <dougshelley66> i would re-iterate that it would be nice if stuff that isn't ever going to merge could be abandonned...
18:10:44 <amrith> would be good to remind people of review guidelines
18:10:53 <amrith> and cleanup old reviews
18:11:42 <tellesnobrega> o/
18:11:43 <peterstac-m> Yeah, I've been trying to look at the older changesets
18:11:57 <peterstac-m> But there's still a lot of noise
18:11:58 * pmackinn thought there was an auto garbage collector
18:12:01 <amrith> want some help getting rid of them
18:12:11 <amrith> the garbage collector was manual
18:12:17 <dougshelley66> pmackinn auto garbage collector was turned off many moons ago
18:12:19 <amrith> we turned off the timeout mechanism
18:12:23 <SlickNik> pmackinn: There used to be an automatic one before infra turned it off.
18:12:48 <pmackinn> enabled infra-wide i take it?
18:12:54 <cp16net> it was thought to be a bad approach of automattically abandoning reviews
18:12:59 <cp16net> yeah
18:13:14 <pmackinn> has its merits
18:14:05 <peterstac-m> I still think that the good outweighs the bad (having it done automatically)
18:14:34 <SlickNik> pmackinn: yes — http://lists.openstack.org/pipermail/openstack-dev/2014-September/045591.html was the thread on the ML where this was discussed.
18:14:37 <cp16net> i think if there is something that just hasnt been rebased and is a good change lets help out the review
18:14:45 * pmackinn stands down
18:15:33 <SlickNik> I've in the past still gone ahead and manually abandoned changes that were stale for sure (after putting in a nice message).
18:15:51 <cp16net> otherwise if its something that we've decided to pass on then we can abandon it and it can be picked up later if needed
18:15:52 <SlickNik> Maybe that's a good compromise.
18:15:59 <peterstac-m> I'd be ok with that   ;)
18:16:14 <pmackinn> untouched for a cycle should get collected imho
18:16:30 <atomic77> could we maybe move changes that are inactive for some period of time into some other branch? at least this way it becomes easier to filter out what's really on our queue
18:16:44 <cp16net> SlickNik: yeah i think thats a good idea if it has not been maintained in a few months
18:17:39 <atomic77> if the author at some point wakes up and realizes the change is important they can always rebase back to master
18:17:58 <atomic77> that way we're not auto-abandoning, but not sure if that's practical though
18:18:05 * pmackinn sees dead branches
18:18:06 <cp16net> atomic77: it is tracked in launchpad on the bug
18:18:24 <cp16net> then if we abandon it then the bug will still be there
18:18:57 <cp16net> then otherse can pick it up and decide if its still valid and pick up the old abandoned review
18:18:58 <dougshelley66> there is nothing destructive about abandoning a change
18:18:59 <amrith> fyi, here's my list of changes URL
18:19:00 <amrith> https://review.openstack.org/#/q/age:10d+is:watched+status:open,n,z
18:19:08 <amrith> the age:10d allows me to filter only recent things
18:19:15 <amrith> you can pick a different number if you'd like
18:20:03 <atomic77> maybe pmackinn 's idea of anything untouched from previous cycle makes the most sense
18:20:38 <cp16net> so i think we agree that abandoning old stale reviews is a good idea
18:20:51 <atomic77> and perhaps can be done during the midcycle -- seems reasonable enough that halfway into mitaka we purge anything that was proposed and is inactive since liberty
18:20:59 <amrith> then go and clean up the old ones that are shown in this filter.
18:21:05 <SlickNik> dougshelley66: There is an aspect that's a bit destructive — once a change is abandoned, it doesn't ever show up in gerrit to anyone. I believe you need to have the actual link to look it up.
18:21:19 <SlickNik> So it's totally not discoverable after you've abandoned it.
18:21:44 <pmackinn> google never forgets
18:21:46 <dougshelley66> except that it would still show up on the launchpad bug and/or BP - but i understand your point
18:22:07 <amrith> and correspondingly, this gives you only the recent changes
18:22:08 <amrith> https://review.openstack.org/#/q/-age:14d+is:watched+status:open,n,z
18:22:14 <amrith> i.e. filters out the old ones.
18:22:16 <SlickNik> Yeah, I'm not convinced either, but the ML thread goes over this aspect too.
18:22:52 <cp16net> yeah i think there is valid points both ways
18:23:27 <SlickNik> cp16net: ++ I think some care must be taken while doing this — so I'm fine with some human making the call (after verifying that a review is actually stale and dead).
18:23:33 <vkmc> there was a discussion puppet devs had... and this is the result of it wrt abandoning old patches http://lists.openstack.org/pipermail/openstack-dev/2015-June/065520.html
18:23:43 <cp16net> #agreed
18:24:01 <vkmc> it's a good reading
18:24:43 <cp16net> yeah looks like it
18:25:12 <pmackinn> vkmc, like it...if it has a -2 it's in someone's consciousness
18:25:13 <SlickNik> vkmc: reading that it seems like they reached a similar conclusion (i.e. manually abandon by a human).
18:25:40 <vkmc> SlickNik, yeah :) that's why I'm bringing this up
18:25:44 <SlickNik> (..if it has a negative review or the change has been addressed in some other way)
18:25:47 <vkmc> kinda sums up what we are chatting here
18:25:50 <SlickNik> yup
18:26:22 <cp16net> i think we agree we need to abandon some reviews
18:26:47 <cp16net> and i think it makes the most sense to make a good judgement call on which ones we do
18:27:07 <pmackinn> cp16net, mid-cycle topic?
18:27:25 <cp16net> sounds like a plan if we dont work it out before then
18:27:29 * pmackinn stumps for mid-cycle
18:27:34 <cp16net> (i hope we do) :)
18:27:44 <ashleighfarnham> pmackinn, isn't that a default topic for midcycles?
18:27:51 <amrith> :)
18:27:55 <SlickNik> #action SlickNik go over old reviews and abandon ones that look extremely crufty and dead
18:28:04 <pmackinn> ashleighfarnham, ouch
18:28:07 <edmondk> definitely would like to clean up old reviews and have them abandoned after a cadence of time
18:28:33 <atomic77> ashleighfarnham, the default topic is that we all like having our code reviewed, but don't like doing reviews :)
18:28:35 * amrith looks at the time
18:28:41 <pmackinn> ashleighfarnham, meant the "process"
18:28:42 <cp16net> aliright i think we agree on that moving on
18:29:01 <cp16net> #topic Adding trove to the openstack client
18:29:11 <cp16net> ashleighfarnham: take it away
18:29:25 <ashleighfarnham> #link https://wiki.openstack.org/wiki/Trove/OpenstackClient
18:29:54 <ashleighfarnham> i'm looking at getting trove added to the openstack client. Looks like a change we have to make in the python-troveclient to plug it into the openstack client
18:30:19 <ashleighfarnham> what I'd like to do is use this as an opportunity to fix anything we don't like with the current python-troveclient
18:31:00 <ashleighfarnham> I'm looking for feedback with regard to things we should change, current pain points, etc. Figured it would be a good place to start before putting together a blueprint
18:31:09 <ashleighfarnham> anyone have any thoughts?
18:31:25 <amrith> could we set a deadline by which we should put stuff in the wikipage/etherpad
18:31:37 <amrith> so ashleighfarnham can go with the input at that point?
18:31:51 <amrith> I have some, will put them in the wiki page.
18:31:57 * SlickNik raises his hand
18:32:17 <SlickNik> can we please add support for the management API?
18:32:20 <ashleighfarnham> amrith, is end of the month long enough for people to look at this?
18:32:20 <SlickNik> pretty please?
18:32:27 <cp16net> :)
18:32:33 <cp16net> SlickNik: +1000
18:32:42 * amrith waits for SlickNik's question to get answered
18:32:44 <atomic77> is it preferred that there is a 1-1 mapping between legacy os-client commands and the commands within the unified client?
18:33:17 <ashleighfarnham> since it is a new client and people are going to have to switch I think we largely have some freedom here to make changes
18:33:25 <amrith> if we add support for management API, I think the issue is more around the UX.
18:33:25 <SlickNik> especially quota-update and reset-state if we want to pick a couple to begin with.
18:33:29 <ashleighfarnham> if a 1-1 mapping doesn't make sense we should make a note of it
18:33:30 <cp16net> atomic77: preffered but not nessesary i think
18:33:44 <vkmc> SlickNik, +1
18:34:12 <amrith> and that's not specific to managemnet API; I think we should not attempt to have a 1-1 mapping but rather have a good UX outline so that later additions can comply wiht this outline
18:34:31 <atomic77> for eg, i personally think that the strong distinction between replica groups and clusters ideally should be invisible to a trove user
18:34:55 <atomic77> so this new client would be an opportunity to present it that way, even if behind the scenes we still manage this differently
18:35:43 <cp16net> remove metadata calls since is doesnt exist
18:35:59 <amrith> cp16net, ++
18:36:18 <SlickNik> atomic77: Intriguing. What do you envision in this case? Is there a consistent set of CLI commands that you can come up with that supports both the scenarios?
18:37:11 <SlickNik> Perhaps we can wiki / draft that set of commands to see what it would look like in a cli?
18:37:59 <atomic77> SlickNik, well for eg it's not clear to me that a user should know or care about why, say, percona-xe with 3 nodes is a "cluster", while a percona with two asych slaves is a regular trove create .. --replica_of
18:38:33 <atomic77> so it could be something like openstack cluster-create .. --topology {"multi-master", "async master/slave"} etc.
18:38:43 <ashleighfarnham> Sounds like we have good ideas. I'm going to take the state of the wiki at the end of the month and work with that to generate a blueprint/spec.
18:38:57 <atomic77> maybe more ambitious than what you envisioned for this spec, but just wanted to through it out there
18:39:03 <atomic77> gah *throw
18:39:24 <ashleighfarnham> atomic77 if we need to break it down into smaller chunks we can do that. Mostly just want to get the ball rolling on this
18:39:53 <amrith> I think it would be useful to think in terms of things in the CLI that the API can validate and things that the taskmanager would have to validate. Also the notion of a mechanism to pass datastore specific stuff through on the CLI in a consistent way.
18:39:59 <cp16net> atomic77: you are jusy saying that the instances act as an atomomous unit if they are slaves or a cluster
18:40:32 <edmondk> as long as we have management functionality, and quota I will be very happy
18:41:12 <cp16net> we can still add the mgmt call to the troveclient
18:41:31 <cp16net> i had a wip to get that in there
18:41:40 <cp16net> i'll look at seeing where that is
18:42:00 <cp16net> #action cp16net look at mgmt cli patch
18:42:14 <edmondk> right now in python-troveclient management binding is commented out
18:42:16 <SlickNik> IIRC someone from unitedstack also put up a patch for that.
18:42:24 <edmondk> if we uncomment it we will at least have the bindings working
18:42:24 <SlickNik> (for the management functionality)
18:42:35 <edmondk> the shell is another addition needed
18:43:12 <edmondk> This  # self.management = Management(self) on client.py under v1
18:43:38 <cp16net> ok so we have a week and a half to get this wiki updated
18:43:58 <cp16net> at the end of the month ashleighfarnham will go forward with this.
18:44:12 <amrith> +1
18:44:22 <cp16net> thanks ashleighfarnham for leading this effort it will be helpful
18:44:40 <ashleighfarnham> :)
18:44:43 <SlickNik> Yup, this is awesome — thanks ashleighfarnham!
18:45:16 <cp16net> #topic open discussion
18:45:32 * amrith coughs ... i have something on the agenda ...
18:45:53 <cp16net> i missed it amrith
18:46:06 <cp16net> sorry
18:46:10 <amrith> sorry, I added it but only saved after the meeting started.
18:46:18 <cp16net> #topic catch-22 with reviews
18:46:20 <amrith> <paste>
18:46:21 <amrith> the two reviews have an odd situation; there is a circular dependency. The change to the client is needed for dsvm to pass, but the client change also requires a corresponding backend change.
18:46:21 <amrith> I've setup the dependencies one way (client depends on server) so the client passes and the server (currently) fails. I'd like the client to merge, and then the server will pass as well.
18:46:21 <amrith> Please see https://review.openstack.org/#/c/245738/ and https://review.openstack.org/#/c/245845/
18:46:22 <cp16net> amrith:
18:46:23 <amrith> </paste>
18:46:50 <amrith> wanted people to know this when they looked at the reviews (looking for some +2's on the client change first).
18:46:53 <amrith> that's all.
18:47:58 <amrith> EOF
18:48:02 <cp16net> ok thanks
18:48:11 <cp16net> #topic open discussion
18:48:15 <cp16net> ok anything else?
18:48:38 <amrith> ./
18:48:58 <amrith> quick question ... follow-up from design summit. how're we doing with action items and things.
18:49:35 * pmackinn stumps for https://etherpad.openstack.org/p/mitaka-trove-midcycle-rsvp
18:50:05 <amrith> pmackinn, could we put the location to rest for good.
18:50:05 <peterstac-m> Maybe we could add that as an agenda item for next week?
18:50:17 <amrith> boston is fine for me but way cold. I'd like someplace warm.
18:50:48 <pmackinn> amrith, did you suggest boston?
18:50:58 <amrith> no, I think Rob did.
18:51:37 * pmackinn needs to know how many sleeping bags to borrow for the northern hosers
18:52:01 <dougshelley66> amrith, it seems like it has already been locked/loaded for Ralleigh
18:52:12 <dougshelley66> didn't this get booked already by pmackinn
18:52:34 <amrith> dougshelley66, I'm just reflecting on the conversation in the etherpad. it was brought up in Tokyo, not sure it was ever 'decided'.
18:52:53 <amrith> maybe it means pmackinn can push up a review and we can +1 it ;)
18:52:56 <dougshelley66> i have no idea who typed that into the etherpad - Rob's colour appeared to be teal
18:53:20 * pmackinn likes Boston...in July
18:53:45 <amrith> ok
18:53:59 <dougshelley66> well, i'm going to book my flight to Raleigh and if no one is there, so be it :)
18:54:07 <amrith> I'll be there.
18:54:15 <pmackinn> http://bit.ly/1lv4JsG
18:54:19 <cp16net> it sounds like from those that are chiming in rather have it in raleigh
18:54:37 <amrith> come on, that's in June. We don't always have that little snow.
18:54:42 * pmackinn starts vacuuming and dusting
18:54:46 <cp16net> lol
18:54:59 <dougshelley66> so pmackinn - you are good with Raleigh and red hat is confirmed to host?
18:55:04 <amrith> i second the idea of Raleigh.
18:55:25 <pmackinn> for the hotel block i need some "harder" numbers
18:55:34 <pmackinn> but we can wait a bit i suppose
18:56:03 <amrith> are you actually planning to get a block or could we just use a redhat code during the booking process?
18:56:07 <pmackinn> but the red hat meeting facility is booked and will be ready
18:56:14 <dougshelley66> pmackinn cool sounds good
18:56:24 <pmackinn> amrith, Red. Hat.
18:56:34 <amrith> redHat?
18:56:37 <pmackinn> trying to get a block
18:56:40 <amrith> sorry Redhat
18:56:45 <pmackinn> gah
18:56:46 <cp16net> alright so we have a location
18:56:51 <cp16net> thats great
18:56:59 <dougshelley66> cp16net yes
18:57:36 <cp16net> lets signup and get this moving forward
18:57:41 <cp16net> :)
18:58:19 <dougshelley66> Tesora folk will be signing up soon
18:58:34 <cp16net> we are getting close to time.
18:58:56 <vkmc> hoping to see some karaoke in the midcycle
18:59:12 <cp16net> amrith: we should follow up on the "action items and things"
18:59:17 <cp16net> :)
18:59:37 <cp16net> thanks everyone
18:59:46 <amrith> thanks cp16net
18:59:47 <amrith> wilco
18:59:49 <cp16net> #stopmeeting
19:00:03 <cp16net> #endmeeting