18:00:23 <amrith> #startmeeting trove
18:00:24 <openstack> Meeting started Wed Feb 17 18:00:23 2016 UTC and is due to finish in 60 minutes.  The chair is amrith. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:27 <openstack> The meeting name has been set to 'trove'
18:01:18 <atomic77> \o/
18:01:22 <tellesnobrega> o/
18:01:34 <dougshelley66> o/
18:01:37 <amrith> let's give everyone a couple of minutes to wander in.
18:01:39 <nshah> o/
18:01:44 <imandhan> o/
18:01:49 <bhaskarduvvuri> o/
18:02:23 <vkmc> o/
18:02:38 <cp16net> i'm have a conflict today so amrith will be running the meeting today
18:02:43 <amrith> courtesy reminder: johnma, peterstac, SlickNik
18:02:56 <amrith> hi cp16net
18:03:22 <amrith> Just a reminder to all ...
18:03:23 <cp16net> hello
18:03:30 <amrith> freenode is experiencing netsplit issues.
18:03:44 <amrith> so be warned that the meeting may be a bit problematic.
18:03:53 <johnma> hello
18:04:05 <pmalik> ☻/
18:04:13 <amrith> let's get started.
18:04:21 <amrith> #topic Trove Pulse Update
18:04:30 <amrith> cp16net, since you are here do you want to talk about this?
18:04:46 <amrith> #link      http://bit.ly/1VQyg00
18:04:55 <amrith> #link http://bit.ly/1VQyg00
18:05:07 <amrith> I will take that as a no.
18:05:27 <amrith> so it looks like we had a bit of a spike last week thanks to the activity at the mid-cycle
18:05:37 <amrith> now the reviews and patches are trending in the right direction.
18:05:55 <amrith> but we have to pick up the pace on the reviews as we get close to the wire.
18:05:57 <cp16net> agree we had a productive week!
18:06:12 <amrith> as the queues will begin to build as we get closer to the release date.
18:06:20 <amrith> So far, the gate has been behaving itself (somewhat).
18:06:32 <amrith> thanks to cp16net and SlickNik for working through some of those issues.
18:06:35 <amrith> late last week.
18:06:59 <amrith> cp16net, anything you'd like to add re: pulse
18:07:23 <cp16net> not really
18:07:35 <cp16net> lets keep up the work
18:07:37 <amrith> ok, anyone else. thoughts, comments re: pulse
18:08:16 <amrith> OK, moving along.
18:08:18 <amrith> #topic Announcements
18:08:27 <amrith> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html
18:08:41 <amrith> The link is to an email from last week.
18:08:50 <amrith> We are getting close to R7
18:08:58 <amrith> we were getting close, we are now in R7
18:09:04 <cp16net> yeah just wanted everyone to see what the focus is overall
18:09:09 <amrith> please read the email ... link attached above.
18:09:32 <amrith> TL;DR. client release freeze is before M3.
18:09:36 <cp16net> main call out here is 2 weeks before release date
18:10:03 <amrith> If you are looking for the Mitaka schedule, http://releases.openstack.org/
18:10:24 <amrith> Sorry, wrong link
18:10:26 <amrith> #link http://releases.openstack.org/mitaka/schedule.html
18:10:55 <amrith> So, please make sure that you have your client changes done in time.
18:11:14 <amrith> Questions?
18:11:38 <amrith> This means we have to make sure we get any python-troveclient patch sets reviewed in time.
18:12:27 <amrith> The full list of open python-troveclient patches at this time is
18:12:29 <amrith> #link https://review.openstack.org/#/q/project:openstack/python-troveclient+status:open
18:13:01 <amrith> I see nothing at this time that would gate release other than the first one, https://review.openstack.org/#/c/281042/
18:13:22 <amrith> (which I just approved, seems reasonable to me).
18:13:35 <amrith> thanks cp16net
18:13:50 <amrith> everyone good with the client side ...
18:14:06 <amrith> is there anything else (other than requirements) that you think must be merged?
18:14:06 <johnma> +1
18:14:09 <amrith> speak now ...
18:14:17 <amrith> going once
18:14:20 <dougshelley66> hang on
18:14:23 <amrith> ok
18:14:32 <dougshelley66> i believe there is a client piece for the module mgmt that peterstac is working on
18:15:46 <amrith> Will you be following up with him on that?
18:16:55 <amrith> yes?
18:17:37 <dougshelley66> yes will do
18:17:56 <amrith> #action dougshelley66 will follow up with peterstac on this.
18:18:31 <amrith> For all ... if you have changes that require client changes, please follow up.
18:18:52 <amrith> cp16net, just to confirm, we have no NON-CLIENT libraries in Trove, correct?
18:19:07 <cp16net> dashboard?
18:19:22 <amrith> that's true, that would be the case for Mitaka
18:19:30 <cp16net> yeah i think thats all
18:19:54 <amrith> so non-client libraries ( dougshelley66 ) Dashboard libraries would be considered non-client libraries ... dloi ^^
18:20:18 <amrith> I don't know of anyone else who may be impacted by the dashboard libraries other than dloi and dougshelley66
18:20:34 <dougshelley66> ok
18:20:36 <amrith> #action dloi dougshelley66 re: non-client libraries for which the deadline is Feb 22-26
18:21:06 <amrith> going once (again)
18:21:10 <cp16net> i started reviewing these dashboard patches
18:21:30 <cp16net> and have the workflow i'm trying to document on how to test them locally
18:21:41 <cp16net> dloi: helped me this morning
18:21:45 <cp16net> thanks dloi
18:22:05 <dloi> glad to help cp16net
18:22:13 <amrith> #link https://review.openstack.org/#/q/project:openstack/trove-dashboard+status:open
18:22:36 <amrith> imandhan, ^^ please see above. You have a review on dashboard as well
18:23:22 <imandhan> yup, I don't think I'll be able to get that working but will try to :)
18:23:39 <imandhan> *working by the deadline is what I meant
18:24:04 <amrith> ok, I see you have it WF-1 so that's cool.
18:24:21 <amrith> that isn't a marked bug so that's fine.
18:24:31 <amrith> marked ~ targeted for Mitaka
18:24:45 <amrith> Ok, that brings us to the next thing on the agenda
18:24:47 <amrith> #topic Health check on outstanding blueprints and features for Mitaka
18:24:56 <amrith> #link https://launchpad.net/trove/+milestone/mitaka-3
18:25:23 <amrith> We are now down to a small number of BP's and reviews marked for Mitaka.
18:25:27 <amrith> I'll quickly run through them.
18:25:37 <amrith> vkmc, yt?
18:25:48 <vkmc> amrith, here
18:25:52 <amrith> The couchdb datastore configuration groups, how's sonali doing?
18:25:55 <amrith> is it on track?
18:26:15 <vkmc> amrith, she is yes, we chatted earlier today, she is now working on addressing the comments on the implementation
18:26:22 <vkmc> amrith, she also replied to the comments on the spec AFAIK
18:26:38 <amrith> #link https://review.openstack.org/#/c/263980/
18:26:47 <amrith> #link https://review.openstack.org/#/c/271781/
18:26:56 <amrith> We need the spec (first link) to be reviewed.
18:27:10 <amrith> vkmc, if you'll be able to take the lead on that, it will help make others follow
18:27:19 <amrith> she just updaed it earlier today, I think
18:27:39 <johnma> vkmc, she didnt quite address cp16net's commentsin the previous patch which is why I wasnt sure whether she was planning to put out another review
18:28:07 <vkmc> amrith, sure
18:28:14 <vkmc> johnma, let me check cp16net comments
18:28:24 <amrith> johnma, vkmc, does it make sense for the two of you to take this up, maybe after the meeting. if you discuss on #openstack-trove, others will be able to pitch in.
18:28:35 <vkmc> sure
18:28:38 <johnma> sure will do that
18:28:39 <amrith> #action johnma vkmc, follow up on couchdb configuration group spec
18:28:45 <amrith> cp16net, how's your stuff? pxc grow shrink and pxc cluster root enable
18:29:33 <cp16net> grow shirnk is merged
18:29:41 <cp16net> root enable is updated yesterday
18:29:46 <cp16net> ready for review i believe
18:30:40 <amrith> cp16net, there's some -1's on pxc cluster
18:31:19 <amrith> #link https://review.openstack.org/#/c/266005/
18:31:22 <cp16net> ok something showed up this morning
18:31:47 <amrith> yes, so there are a number of more blueprints and instead of going through each one, one at a time. how about we try this ...
18:32:19 <amrith> is anyone working on a BP or change that you feel is in jeoprady, or where you need something (review, response, help) speak now ...
18:32:56 <amrith> that request goes out to vkmc, imandhan, mvandijk, vgnbkr, peterstac, atomic77, cp16net, pmalik,
18:33:00 <cp16net> ok there isjust a minor change i need to make on that patch
18:33:29 <amrith> for bugs, dougshelley66 and me
18:34:06 <amrith> fyi: I have to get cracking on my  bug relative to devstack
18:34:33 <amrith> ok, so if there is a review, or a BP that is stalled, please speak now ...
18:35:02 <johnma> amrith, i will be putting out another patch for my couchdb backups today - from last week's feedback I needed to add data for int-tests.
18:35:19 <johnma> apart from that I am good
18:35:30 <amrith> ok, johnma
18:35:46 <amrith> which is a good lead in to the next topic on the agenda, right?
18:35:54 <johnma> yes
18:35:56 <imandhan> yup
18:36:02 <amrith> #topic [imandhan, johnma] Follow up discussion from midcycle on handling of users while performing db2 backup and restore. Associated Review #246709
18:36:10 <amrith> #link https://review.openstack.org/#/c/246709/
18:36:10 <imandhan> I wanted to bring up the issue of users when handling db2 backups in trove as discussed at the mid cycle previously.
18:36:34 <imandhan> We’ve been discussing this internally with DB2 experts and they confirmed that DB2 does not manage users and hence backups are just database backups. So moving forward we have two options-
18:36:43 <imandhan> option 1: to not implement user backups
18:37:14 <imandhan> option 2: to be consistent with other datastores in trove, partially implement user backups by getting the list of users from the system catalog tables and then create them on the new instance with default pwds
18:37:26 <vgnbkr> amrith, I'm having to rework the notifications change as it has been waiting for a review so long that it is now out of date.  The MariaDB clustering change is also waiting on reviews.
18:37:57 <amrith> vgnbkr, one second. let's finish up on the db2 thing. will get back to you on your items.
18:38:28 <amrith> imandhan, I have some questions for you re: those options.
18:38:35 <imandhan> sure
18:38:46 <amrith> IIRC, the discussion at mid-cycle was to find out from DB2 experts how they wish to do backups of a db2 database.
18:39:03 <amrith> and to then implement those best practices in the db2 backup code within trove.
18:39:20 <amrith> I think the options you present seem to address the issue from the Trove perspective
18:39:33 <amrith> rather than the perspective of an end-user of Trove who is really looking for DB2 best practices.
18:39:54 <imandhan> Based on discussions I have had with DB2 folks, the best way to move forward is to go up with option 2
18:39:57 <amrith> Therefore I think the options you present may be the wrong ones to be considering at this stage.
18:40:10 <imandhan> but I want a green light from trove perspective
18:40:16 <imandhan> to go ahead and implement it
18:40:27 <mvandijk> ./
18:40:34 <amrith> OK, speaking for myself, I believe that ...
18:40:41 <mvandijk> I think #1 is the way to go.
18:40:43 <amrith> I should shut up and let mvandijk speak
18:41:04 <amrith> go ahead mvandijk
18:41:09 <mvandijk> typing
18:41:13 <amrith> eager minds would love to know more ;)
18:41:41 <johnma> so amrith, from DB2 perspective they dont manage users but only database backups
18:42:08 <mvandijk> In the db2 world back and restore is not concerned with users, so I don't think we should try and magically make it fit trove's perspective.
18:42:21 <mvandijk> copying system users around is not a good path to go down
18:42:37 <imandhan> is it okay to be inconsistent within trove though?
18:42:46 <mvandijk> sure. we do it all the time :)
18:43:06 <mvandijk> database engines are different
18:43:17 <johnma> which is why the basic authentication mechanism for DB2 is os authentication or they also provide plugins for LDAP and kerberos based systems which manage users
18:43:24 <mvandijk> what you have now does what a db2 dba expects us to do
18:44:09 * amrith sets a stopwatch for 3m
18:44:29 <johnma> I agree with mvandijk that option 1 might be the right approach and 2) is trying to fit to  Trove's way of doing backups
18:44:44 <imandhan> ok well if it's ok to not fit into the ideal trove scenario we should go with 1
18:45:08 <mvandijk> amrith any arguments?
18:45:10 <imandhan> and db2 within trove uses os auth so there's no question about users being backed up anyway
18:46:04 <mvandijk> no arguments here
18:46:10 <amrith> ok, so let me ask ...
18:46:19 <amrith> caveat: I know nothing about db2
18:46:27 <amrith> If I had a db2 database
18:46:35 <amrith> and like other databases, I had permissions for objects
18:46:42 <amrith> how does a backup handle these permissions?
18:46:47 <amrith> when I restore the database
18:46:59 <amrith> are the permissions (a) gone, (b) a mess, (c) perfectly A-OK
18:47:00 <mvandijk> recreate users to match the schema owners i believe
18:47:20 <amrith> that's question #1
18:47:24 <amrith> Here's question #2
18:48:02 <amrith> if I wandered up to a bunch of DB2 DBA's and they were running a DB2 database and I asked them what they'd expect of a backup (using whatever the state of the art tools are for DB2 backups), would that answer include that on restore, users were restored?
18:48:23 <amrith> And finally, here's question #3
18:48:51 <amrith> Should we do what we set forth as the common abstraction for backups, or what a DBA for the specific database would expect even if it were different from our common abstraction?
18:48:56 <amrith> those ar the three questions I have.
18:49:26 <amrith> And I realize that we may not be able to (or have the time to) answer those here and now.
18:49:34 <amrith> So if we have to table this and pick it up later, let's do that.
18:49:35 <johnma> when the databases are restored, the permissions will be stored in the syscatalog tables
18:49:40 <mvandijk> for #2 - if not using ldap/kerberos you would be expected to recreate the users manually
18:49:43 <amrith> but I will ask what the timeframe is on this.
18:49:44 <imandhan> DB2 DBAs would not expect users to be restored
18:49:47 <amrith> when do we need to know?
18:50:15 <amrith> ok, sounds like the answer is:
18:50:20 <amrith> do a backup of data and system tables
18:50:26 <amrith> on restore, restore data and system tables.
18:50:37 <johnma> these users will have to be created on the new instance
18:50:38 <amrith> if and when the os users are created, the permissions will fall into place.
18:50:39 <amrith> yes?
18:50:46 <imandhan> right
18:50:50 <johnma> oh boy, I am typing real slow.
18:50:57 <amrith> OK, so that answers question  1 and 2.
18:50:59 <amrith> What then about 3?
18:51:13 <johnma> reading 3)
18:51:21 <amrith> I interpret mvandijk's answer to mean that he would do what the DBA would expect of each database.
18:51:25 <amrith> and each database is different.
18:51:46 <amrith> I don't see anything in this implementation that would preclude a later addition to allow backup to backup and restore users.
18:51:52 <imandhan> I +1 mvandijk on that if trove is ok with a different approach
18:51:57 <amrith> so I would be inclined to say, yes, do what you are describing.
18:52:12 <mvandijk> +1
18:52:13 <amrith> don't bother about users, that's the end-user's issue to address.
18:52:36 <imandhan> right, that's the approach db2 takes and therefore the various auth methods outside of db2
18:52:45 <amrith> I would suggest you document it as such and we can revisit later if other information comes up which necessitates it.
18:52:49 <amrith> is that OK to all?
18:53:04 <imandhan> document it in comments in the code or changes to spec?
18:53:07 <johnma> so Amrith, when we talk about backups in Trove, do we specifically mention anywhere that it is both database and user backup
18:53:24 <amrith> johnma, not that I know of.
18:53:42 <amrith> I believe that we just say that we take a backup of a database.
18:53:50 <johnma> thats right
18:54:27 <amrith> ok, so in the interest of time, and since I promised vgnbkr that we'd get back to him, I'm going to move forward.
18:54:41 <amrith> #topic mariadb clustering and notification changes [vgnbkr]
18:54:57 <amrith> Morgan, the changes you mention are
18:55:03 <amrith> #link https://review.openstack.org/#/c/227870/
18:55:11 <amrith> and #link https://review.openstack.org/#/c/276808/
18:55:14 <amrith> are they not?
18:55:51 <amrith> Folks, both of these are targeted for Mitaka and we need to get them reviewed.
18:55:57 <vgnbkr> Yes, I think so.  I was just responding to your question to me.
18:56:05 <amrith> Could you all please put them on your list of things to review.
18:56:42 <vgnbkr> But as I said, don't look at https://review.openstack.org/#/c/227870/ (Ceilometer Notifications) until I update it.
18:57:00 <amrith> ok, <all> ^^
18:57:31 <amrith> moving on
18:57:37 <amrith> #topic Open Discussion
18:58:00 <cp16net> #info i'm working on adding trove support to openstack4j in my spare time. https://github.com/gondor/openstack4j/issues/299
18:58:43 <amrith> interesting
18:58:47 <amrith> will take a look at that
18:58:52 <amrith> others?
18:59:10 <cp16net> i've made some progress on it but it would be nice to get a ruby version as well
18:59:29 <cp16net> i think that will get us to the # of apis to help the "stable" tag
18:59:43 <amrith> the maturity score, yes.
18:59:50 <cp16net> yeah thats what i was getting at
18:59:54 <amrith> anyone else, we're close to being out of time.
19:00:09 <amrith> going once
19:00:18 <amrith> going twice
19:00:27 <amrith> #endmeeting