18:00:07 <SlickNik> #startmeeting trove-bp-review
18:00:08 <openstack> Meeting started Mon May  5 18:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:08 <denis_makogon> SlickNik, are we still going to move all possible features from -manage to public API ?
18:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <openstack> The meeting name has been set to 'trove_bp_review'
18:00:44 <SlickNik> Giving folks a couple of minutes to trickle in to the bp review.
18:00:58 <cp16net> yea
18:01:06 * juice is trickling
18:01:18 <SlickNik> Just wanted to mention a point of order.
18:01:24 <dougshelley66> denis_makogon, SlickNik - isn't the point to move away from trove-integration to tempest with devstack CI?
18:01:30 <openstackgerrit> Sushil Kumar proposed a change to openstack/trove: Adds performance_schema to ignore_dbs  https://review.openstack.org/92176
18:01:49 <denis_makogon> dougshelley66, of course, but it's like temporary solution
18:02:09 <SlickNik> dougshelley66: Yes, the plan is to move away from trove-integration.
18:02:36 <juice> slicknik - what was your point of order
18:02:51 <SlickNik> dougshelley66: Let's chat after the bp meeting.
18:02:57 <dougshelley66> SlickNik certainly
18:03:10 <denis_makogon> mattgriffin, it's your turn, i guess
18:03:21 <mattgriffin> denis_makogon, hello!
18:03:33 <denis_makogon> mattgriffin, hello, Mat =)
18:03:41 <mattgriffin> so i've proposed 3 BPs
18:03:59 <mattgriffin> 1. https://blueprints.launchpad.net/trove/+spec/support-percona-xtrabackup-2.2
18:04:15 <denis_makogon> #link https://blueprints.launchpad.net/trove/+spec/support-percona-xtrabackup-2.2
18:04:21 <mattgriffin> there was a question last week about backwards compability
18:04:27 <mattgriffin> of backups
18:04:45 <SlickNik> mattgriffin: hang on one sec.
18:04:49 <mattgriffin> SlickNik, ack
18:05:25 <SlickNik> I don't think cores are around yet.
18:05:30 <grapex_> Sorry, got disconnected
18:05:30 <SlickNik> grapex just got here.
18:05:34 <SlickNik> np.
18:05:42 <SlickNik> So just a point of order before we start.
18:05:59 <SlickNik> To be fair to all parties involved — if you submit more than one unrelated bp per review meeting — only the first one will be talked about as part of the queue.
18:06:11 <openstackgerrit> Sushil Kumar proposed a change to openstack/trove: Resolves volume resize issue  https://review.openstack.org/80315
18:06:28 <SlickNik> We can talk about the other ones if we have time.
18:06:39 <grapex_> SlickNik: I like it
18:07:13 <SlickNik> Okay, with that out of the way.
18:07:21 <SlickNik> #topic Percona support
18:07:39 <SlickNik> mattgriffin:
18:07:42 <mattgriffin> SlickNik, hi :)
18:07:42 <SlickNik> go ahead
18:08:30 <mattgriffin> hi all. i created some Summit proposals but was told that the best route was to submit BPs
18:08:38 <SlickNik> So a couple of things regarding the bps.
18:08:41 <mattgriffin> ok
18:09:27 <SlickNik> It's still early days for supporting xtradbcluster (https://blueprints.launchpad.net/trove/+spec/support-pxc-5.5-and-5.6) since we don't have a clustering API in trove yet.
18:10:00 <mattgriffin> SlickNik, ack
18:10:29 <denis_makogon> SlickNik, agreed, looks like another package for current percona support
18:10:45 <konetzed> SlickNik: *fingers crossed* for clustering :D
18:10:48 <mattgriffin> SlickNik, just looking for ways that percona can plug into the team and help ... perhaps that API is a way forward during Juno
18:11:25 <denis_makogon> mattgriffin, we can ask them to join amcrn's design sessions
18:11:27 <SlickNik> We have a summit session on the clustering API design, and plan to have it nailed by then.
18:11:38 <mattgriffin> cool
18:11:40 <SlickNik> (amcrn is doing a great job of leading that)
18:12:22 <SlickNik> As for support for percona-server. THe plan is to support it through the mysql-manager itself.
18:12:41 <denis_makogon> SlickNik, sound very reasonable
18:12:44 <SlickNik> There's a session on unifying guest-agents that will discuss that and hub_cap's driving that one.
18:12:46 <mattgriffin> SlickNik, any work needed to get PS 5.6 into the mix for support?
18:12:58 <cp16net> yeah it should be similar enough not to have another impl for percona
18:13:39 <mattgriffin> SlickNik, ok... then chat about that in ATL
18:13:42 <mattgriffin> ?
18:13:49 <SlickNik> mattgriffin: Should be fairly straightforward; don't think there's an issue there.
18:14:44 <SlickNik> cp16net: Yes, the idea is to have the mysql guest support percona as well.
18:15:07 <SlickNik> mattgriffin: So for xtrabackup, was there a backward compat issue?
18:15:32 <mattgriffin> SlickNik, i checked into it. no issue but GeorgeLorch is here if there are additional questions
18:17:01 <SlickNik> mattgriffin: Okay, sounds good. In that case, it's probably okay for us to move to xtrabackup- 2.2 for backup/restore.
18:17:09 <mattgriffin> SlickNik, with xtrabackup, there are likely features that trove isn't using that would be helpful to users.
18:17:16 <mattgriffin> SlickNik, cool
18:17:20 <SlickNik> Will follow up with GeorgeLorch about new features.
18:17:30 <mattgriffin> SlickNik, great!
18:17:41 <SlickNik> Thanks mattgriffin.
18:17:46 <mattgriffin> SlickNik, thank you
18:18:01 <cp16net> i see last time juice asked about direct integration with XtraBackup to s3/swift
18:18:50 <mattgriffin> cp16net, that's unfortunately not going to be available until late 2014 in 3.0
18:19:14 <SlickNik> Okay, let's move on.
18:19:17 <SlickNik> #topic Instance database log manipulations
18:19:28 <denis_makogon> #link https://blueprints.launchpad.net/trove/+spec/dbinstance-log
18:19:53 <denis_makogon> last time this one appeared, were asked several questions
18:20:03 <denis_makogon> you can find them at the wiki page
18:20:23 <denis_makogon> questions are related to log rotation
18:20:30 <denis_makogon> and sys log
18:20:37 <denis_makogon> *sys log service
18:21:12 <denis_makogon> short answer to rotation - it can be done within scheduled task
18:21:33 <konetzed> why cant you use logrotate?
18:21:46 <denis_makogon> konetzed, we can, that's what i wrote
18:22:06 <konetzed> denis_makogon: sorry just saw that link, must have glanced over it first time
18:22:09 <denis_makogon> konetzed, but to keep full log history we need to push log to Swift
18:22:43 <denis_makogon> once rotation time comes, guest pushes database log into the Swift
18:23:05 <denis_makogon> but this task can be accomplished once scheduled task appears
18:23:23 <denis_makogon> we had design session for scheduled tasks
18:23:35 <denis_makogon> *have
18:23:51 <esmute> denis_makogon: How can you configure the the DB log config? rotation, file size and all the other logging goodness
18:24:11 <denis_makogon> esmute, everything is written at wiki page
18:24:22 <denis_makogon> esmute, size, schedule, file
18:24:24 <denis_makogon> etc
18:24:56 <esmute> denis_makogon: ok.. i just read the API portion
18:25:06 <denis_makogon> esmute, cool =)
18:25:15 <amcrn> denis_makogon: your wiki mentions the template, it doesn't mention how it's actually rendered with dynamic values
18:25:56 <denis_makogon> amcrn, https://wiki.openstack.org/wiki/Trove/DBInstanceLogOperation#Log_files_rotation
18:26:06 <denis_makogon> {{ how_often }}
18:26:08 <amcrn> where does "actual rotation count" come from
18:26:22 <denis_makogon> amcrn, from guest config
18:26:28 <juice> denis_makogon: I still feel that either this is a generic component that could be added to dbaas as something installable or a 3rd party component - i.e. why are we building this?
18:26:57 <SlickNik> denis_makogon: Your wiki doesn't mention any API endpoints for this. What's the endpoint that I need to actually hit?
18:27:13 <denis_makogon> juice, from PaaS level perspective, you cannot access the VM directly, only through some API
18:27:19 <amcrn> denis_makogon: https://wiki.openstack.org/wiki/Trove/DBInstanceLogOperation#Configuration is missing your guest config
18:27:42 <denis_makogon> amcrn, that's true
18:27:44 <juice> denis_makogon: I understand that but log shipping is a solved issue
18:27:49 <denis_makogon> amcrn, thanks for catch
18:27:50 <vipul> denis_makogon: We should forget about iteration 2 for now.. just focus on iteration 1.  I'm missing how the user would save off a log file.. and how the deployer would choose which files can be saved.. and what timestamp a saved log file represents
18:28:03 <denis_makogon> juice, we cannot use syslog server
18:28:44 <denis_makogon> vipul, log files will be shipped to Swift container
18:28:47 <cp16net> denis_makogon: can how do you add log files that are not specified in this "default" setup of log files?
18:29:14 <vipul> denis_makogon: i understand that.. i feel like this can be simplified sooo much for v1
18:29:20 <denis_makogon> cp16net, i'm specifying at database logs only
18:29:29 <denis_makogon> vipul, how ?
18:29:30 <SlickNik> Okay, so I don't want this to turn into a design session.
18:29:39 <denis_makogon> SlickNik, agreed
18:29:45 <kevinconway> SlickNik: what if....
18:29:52 <denis_makogon> lets talk about meeting
18:30:12 <denis_makogon> #action Fix wiki page (conf. section)
18:30:16 <vipul> 1. we need an endpoint that let's a user 'save' a file.. given the name of a file.. 2. we need an endpiont that lists all saved files, and their timestamps.. Done
18:30:37 <SlickNik> So I think we all agree that the BP needs some better definition around phase 1 of this.
18:30:44 <SlickNik> denis_makogon: thanks.
18:30:46 <denis_makogon> vipul, that's what i proposed as v1
18:31:00 <esmute> denis_makogon: so only the logs that are created/saved will be the ones accessible?
18:31:07 <denis_makogon> esmute, yes
18:31:20 <denis_makogon> esmute, only database logs
18:31:38 <SlickNik> Let's defer this until next week, when denis_makogon updates the page with this info.
18:31:39 <denis_makogon> let's move forward
18:31:45 <esmute> so if i want daily logs (or hourly) i would have to add a cronjob/script to run every hour and invoke the dblog-create api?
18:31:45 <SlickNik> thanks #denis_makogon
18:31:47 <denis_makogon> SlickNik, agreed
18:32:02 <denis_makogon> esmute, lets talk after
18:32:10 <SlickNik> #topic Update database instance name
18:32:14 <SlickNik> nehav around?
18:32:17 <NehaV> hey
18:32:32 <NehaV> its a bp to allow users to rename db instance
18:32:37 <denis_makogon> one question, what's the justification of it ?
18:32:45 <denis_makogon> what it stands for ?
18:32:47 <NehaV> a change to the existing update instance call
18:33:08 <NehaV> Users have requested the ability to rename instances after they are created
18:33:22 <denis_makogon> NehaV, nova allows it ?
18:33:34 <NehaV> yes
18:33:36 <iccha1> yes
18:33:42 <denis_makogon> NehaV, why does DNS is not enough?
18:33:44 <iccha1> all projects allow name changes
18:33:52 <iccha1> its id changes which are not allowed
18:33:57 <cp16net> i think a good example is i created a dev-instance and i'm now using it in prod so i'd like to change the name to prod-instance
18:34:14 <NehaV> a user should be allowed to change the name of their instance
18:34:48 <denis_makogon> cp16net, thanks for an example
18:34:50 <grapex_> Sounds pretty simple. Even when you're just making test instances, it can be painful sometimes when you can't rename them
18:34:53 <amcrn> makes sense to me
18:34:56 <denis_makogon> NehaV, does heat allows that ?
18:35:03 <SlickNik> one question.
18:35:06 <cp16net> yeah and nothing should be tied directly to the name any way
18:35:09 <SlickNik> NehaV: So the bp mentions it being a PUT, but I think it's more likely a PATCH since you're not including all the json that specifies the resource.
18:35:14 <NehaV> i m not sure about heat
18:35:20 <denis_makogon> SlickNik, ++
18:35:22 <iccha1> cp16net: +1
18:35:24 <cp16net> tru
18:35:44 <vipul> is the plan to propogate the name change to the nova instance?
18:35:46 <denis_makogon> NehaV, please take a look at heat, since we're planning to move at it, as soon as possible
18:35:51 <iccha1> SlickNik: then the config call wpould also have to change ?
18:36:23 <vipul> the one issue i see is the nova instance name is usually also the hostname of the VM
18:36:37 <denis_makogon> vipul, ++
18:36:41 <vipul> so we are indirectly relying on it
18:36:45 <esmute> vipul: Does renaming a nova instance, rename the hostname?
18:36:54 <vipul> esmute: good question, i'm not sure
18:36:54 <denis_makogon> esmute, yes
18:37:06 <iccha1> do u propagate instance name to nova server name?
18:37:38 <denis_makogon> iccha1, yes, we're doing it
18:37:46 <vipul> iccha1: we do.. unless DNS is enabled
18:37:57 <denis_makogon> vipul, that's also true
18:37:58 <grapex_> Maybe I'm missing something- why is it important to rename the Nova instance name?
18:37:58 <cp16net> yeah then its the dns name
18:38:10 <grapex_> The issue is though DNS names are configured via a strategy
18:38:31 <grapex_> At Rax they are these weird guid looking things that don't have to be the same as anything else
18:38:32 <vipul> grapex_: if you don't use dns in Trove, the instance name = nova instance name
18:38:40 <denis_makogon> also, heat changes host name "as it want's", by adding huge hash to resource name
18:39:01 <grapex_> vipul: Trust, but I guess I don't get why the nova and Trove names would have to be the same.
18:39:38 <vipul> well the only issue i see is the hostname of the VM will not be tied to the Trove instance name
18:39:46 <denis_makogon> NehaV, are you planning to rename instance hostname, or just Trove instance name ?
18:40:06 <denis_makogon> vipul, same for me
18:40:09 <NehaV> trove instance name
18:40:17 <vipul> so for example.. we use that hostname + uuid + other stuff today to generate a 'salt key'
18:40:21 <denis_makogon> in this case, it's valid
18:40:25 <vipul> we can probably work around that..
18:40:41 <vipul> but just raising it as a potential issue
18:41:15 <denis_makogon> i guess we can changes Trove instances name, since it's not chained with compute instance name
18:41:17 <grapex_> vipul: I see.
18:41:22 <saurabhs> like nova when you change name of the instance, nothing on the instance is affected, updated name is visible in nova list, but if you do 'hostname' on the instance you will continue to see the old name.
18:41:22 <iccha1> we should be relying only on ids, and never on names.
18:41:49 <saurabhs> we should do something similar change it it in trove database only and not change anything in nova
18:41:53 <denis_makogon> iccha1, we just doing it
18:42:04 <denis_makogon> saurabhs, that's valid
18:42:11 <esmute> saurabhs: so nova rename does not update the hostname?
18:42:26 <kevinconway> iccha1: but ba3e352a-577f-4a40-9646-aaca5acf86f8 is so hard to pronounce
18:42:40 <saurabhs> it updates it only in nova list I guesst. on instance for sure 'hostname' command returns you old name of the instance
18:42:55 <denis_makogon> kevinconway, at least you can try ;)
18:43:07 <iccha1> shakespeare said whats in a name kevinconway
18:43:26 <SlickNik> Okay, I think we know pretty well what this entails.
18:43:36 <SlickNik> Let's get a quick vote:
18:43:53 <vipul> yea we should be able to work around it..
18:43:57 <esmute> +1 update both trove and nova instance
18:44:08 <denis_makogon> +1 only for Trove instances
18:44:18 <openstackgerrit> Anna Shen proposed a change to openstack/trove-integration: Trove guestagent should not use sample conf  https://review.openstack.org/88478
18:44:19 <openstackgerrit> Anna Shen proposed a change to openstack/trove-integration: Add neutron switch for int tests  https://review.openstack.org/87856
18:44:21 <openstackgerrit> Anna Shen proposed a change to openstack/trove-integration: Add support for a neutron-based install  https://review.openstack.org/78123
18:44:28 <cp16net> #vote yes
18:44:32 <annashen> sorry guys
18:44:51 <SlickNik> #vote update instance name? yes-only-trove, yes-trove-and-nova, no
18:45:04 <SlickNik> #startvote update instance name? yes-only-trove, yes-trove-and-nova, no
18:45:04 <openstack> Begin voting on: update instance name? Valid vote options are yes-only-trove, yes-trove-and-nova, no.
18:45:05 <denis_makogon> #vote yes-only-trove
18:45:06 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:45:07 <grapex_> I'd like to make it an option
18:45:09 <esmute> #vote  yes-trove-and-nova
18:45:11 <NehaV> #vote yes-only-trove
18:45:11 <grapex_> #vote yes-only-trove
18:45:13 <saurabhs> #vote yes-only-trove
18:45:17 <robertmyers> #vote yes-only-trove
18:45:19 <amcrn> #vote yes-only-trove
18:45:24 <iccha1> #vote yes-only-trove
18:45:25 <grapex_> I want other deployers to be able to change the Nova name and do other things if they need to
18:45:37 <vipul> #vote yes-only-trove
18:45:43 <grapex_> Maybe we could add a function name to the configs that gets called when the name is changed, and by default its None
18:45:47 <SlickNik> I'm with grapex_ on this one.
18:45:54 <cp16net> #vote yes-only-trove
18:46:03 <denis_makogon> #vote yes-only-trove
18:46:05 <grapex_> SlickNik: The options didn't entail that
18:46:10 <grapex_> but I'm sure it could be a fast-follow
18:46:32 <SlickNik> sure
18:46:37 <SlickNik> #endvote
18:46:38 <openstack> Voted on "update instance name?" Results are
18:46:38 <kevinconway> grapex_: you mean like an event callback?
18:46:39 <openstack> yes-trove-and-nova (1): esmute
18:46:40 <openstack> yes-only-trove (9): iccha1, robertmyers, saurabhs, denis_makogon, amcrn, cp16net, grapex_, NehaV, vipul
18:46:47 <esmute> landslide
18:47:05 <iccha1> SlickNik: i would still like your put vs patch concern addressed though
18:47:34 <SlickNik> iccha1: same here
18:47:58 <SlickNik> IIRC, config groups used patch, but I'll have to check the code.
18:47:59 <cp16net> yeah but i think it should be ok to start on the small change
18:48:04 <SlickNik> cp16net might have a better idea.
18:48:12 <SlickNik> Let's take that offline and work it out.
18:48:20 <cp16net> yeah we have added patch for that
18:48:28 <cp16net> for attach/detach
18:48:30 <iccha1> cp16net: configurations uses patch?
18:48:32 <NehaV> the current update instance call has put for updating a config group to an instance
18:48:36 <iccha1> cool the docs are updated then
18:48:42 <cp16net> iccha1: yup
18:48:42 <iccha1> *outdated
18:49:00 * cp16net thinks i'm up to date :-P
18:49:06 <iccha1> https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29
18:49:07 <SlickNik> grapex_: I'm okay with having the trove-only option go in. We can fast follow with a config and nova rename if needed. :)
18:49:11 <SlickNik> Let's move on.
18:49:42 <SlickNik> #topic Pluggable conductor manager
18:49:45 <SlickNik> boden?
18:50:01 <denis_makogon> seems he's out
18:50:16 <SlickNik> I'm not sure what his IRC nick is.
18:50:38 <SlickNik> #topic Allow configs to be rendered based on datastore version
18:50:40 <denis_makogon> SlickNik, boden
18:51:04 <SlickNik> cp16net: all yours
18:51:11 <denis_makogon> ++ for this BP
18:51:38 <SlickNik> I think this really is a bug.
18:51:38 <cp16net> yeah this needs to change a bit
18:51:51 <cp16net> grapex_: passed this off to me and i think i am a little behind... :-p
18:51:52 <cp16net> sorry
18:52:00 <vipul> wasn't there talk of collapsing the version + datastore into a single field
18:52:06 <vipul> if that happens, is this a solved problem
18:52:25 <grapex_> vipul: A single field in the class named "Datastore"?
18:52:35 <cp16net> well the templates we have are stored in /tempatles/{manager}/
18:52:55 <cp16net> right now and we cant have like multiple tempaltes for different versions...
18:52:55 <vipul> grapex_: yes.. datastore_name may imply 'datastore + version'
18:53:05 <cp16net> like mysql 5.1 or 5.5
18:53:11 <grapex_> vipul: Well today the template is only picked using the datastore's manager
18:53:25 <cp16net> this makes the path easier to follow and make configurations for each version
18:53:31 <denis_makogon> as for me, we should have root template /template/{datastore}/root.config
18:53:38 <cp16net> but still defaulting back to the manager if the others are not found
18:53:48 <denis_makogon> and other templates are extending the root.config
18:54:25 <robertmyers> more options are better
18:54:34 <cp16net> so after explaining that part... are there any questions about this ?
18:54:34 <SlickNik> cp16net / denis_makogon: I think both of you are saying basically the same thing.
18:54:38 <grapex_> robermyers: ++
18:54:48 <vipul> cp16net: so you think it's better to derive the tempalte from datastore_version and if it does collapse into a single record.. then this would just follow?
18:54:53 <grapex_> I'm sure we'll change this and then next week a deployer will wish we'd added something else
18:54:56 <denis_makogon> SlickNik, cp16net if that's so, than cool =)
18:55:14 <grapex_> vipul: the point here is to get the template from both the datastore name and the version
18:55:32 <denis_makogon> grapex_, ++
18:55:34 <grapex_> if it becomes a single record, that's ok, because the blueprint currently tries multiple paths
18:55:50 <grapex_> the first is something like /template/{datastore_name}/{datastore_version}
18:55:56 <cp16net> vipul: yeah this makes the deployer able to make the templates in a more specific place
18:55:57 <vipul> grapex_: yep, i got that.. i'm all for it.. just might become moot if someone does implement the single record solution
18:56:02 <amcrn> i generally agree with the proposal, but have a few minor nits (but that can be discussed at a later time in a smaller setting)
18:56:04 <robertmyers> we can always change the paths we check
18:56:14 <grapex_> vipul: Sure
18:56:20 <denis_makogon> robertmyers, agreed
18:56:26 <grapex_> but that's relying on a pretty huge refactor to the datastore stuff
18:56:34 <cp16net> yeah thats just a list of configuration paths
18:56:46 <grapex_> I am a horrible cynical man but I don't know if I believe that will happen
18:56:56 <grapex_> Maybe we can have a hack-a-thon at the summit and change datastores. :)
18:57:07 <vipul> grapex_: fair enough it probably won't anytime soon
18:57:15 <cp16net> amcrn: we can chat later and make sure we are on the same page
18:57:21 <amcrn> cp16net: sounds good
18:57:24 <cp16net> :)
18:57:30 <grapex_> vipul: Cool. Not kidding about the hackathon btw
18:57:33 <SlickNik> So I'm good with this one as well.
18:57:57 <cp16net> i think its straight forward
18:58:10 <robertmyers> +1
18:58:11 <SlickNik> #startvote Allow configs to be rendered based on datastore version? yes, no
18:58:13 <openstack> Begin voting on: Allow configs to be rendered based on datastore version? Valid vote options are yes, no.
18:58:14 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:58:19 <robertmyers> #vote yes
18:58:20 <cp16net> #vote yes
18:58:20 <SlickNik> #vote yes
18:58:21 <amcrn> #vote yes
18:58:24 <vipul> #vote yes
18:58:26 <esmute> #vote yes
18:58:27 <denis_makogon> #vote yes
18:58:33 <grapex_> #vote yes
18:58:41 <NehaV> #vote yes
18:58:49 <SlickNik> #endvote
18:58:50 <openstack> Voted on "Allow configs to be rendered based on datastore version?" Results are
18:58:51 <openstack> yes (9): SlickNik, robertmyers, denis_makogon, amcrn, cp16net, esmute, NehaV, vipul, grapex_
18:59:07 <SlickNik> Okay, go for it cp16net
18:59:30 <SlickNik> And that's all we have time for this week.
18:59:37 <SlickNik> #endmeeting