17:59:40 <SlickNik> #startmeeting trove-bp-review
17:59:41 <openstack> Meeting started Mon Apr 21 17:59:40 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:44 <openstack> The meeting name has been set to 'trove_bp_review'
17:59:51 <SlickNik> okay, that's better.
18:00:08 <SlickNik> amrith: Let's give folks a couple of minutes to trickle in
18:01:50 <kevinconway> #topic do permissions work right on this thing?
18:01:55 <kevinconway> darn
18:01:58 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:02:18 <SlickNik> kevinconway: I think only the person who started the meeting can change the topic.
18:03:12 <esmute> kevinconway: Yeah permission is working.. i just did a /kick kevinconway and you are still here
18:03:31 <SlickNik> #topic: Unify common code in guest agent configurations
18:03:44 <SlickNik> #topic Unify common code in guest agent configurations
18:03:53 <SlickNik> maybe not?
18:03:56 <amrith> I'll take that as my cue
18:04:05 <amrith> so, SnowDust and I put this thing together
18:04:17 <amrith> subsequently, it appears that hub_cap has made some changes
18:04:30 <amrith> and those represent the direction we may want to go
18:04:33 <hub_cap> hey so
18:04:40 <hub_cap> afte some thought on this, and a ton of refactoring
18:04:40 <amrith> so, for the present, I say table this blueprint
18:04:48 <hub_cap> im not sure i like the approach im taking
18:04:51 <hub_cap> lets chat about it for a sec amrith
18:04:56 <amrith> ok, sure
18:05:04 <hub_cap> so there _will_ be datastore specific items that the api/taksmgr need to know about
18:05:11 <hub_cap> and frankly the guest may never care about
18:05:28 <hub_cap> let me find an exampl eof the one i was lookin at
18:05:38 <hub_cap> hmm its been a while i dont want to waste our time
18:05:49 <hub_cap> so to the config loading snowdust has done
18:06:07 <hub_cap> i think that it might be valid to have those as config options groups within the main trove config
18:06:10 <hub_cap> cfg.mysql.blah
18:06:20 <hub_cap> some of them dont matter, like the mount_point
18:06:23 <hub_cap> that was an easy refactor
18:06:30 <hub_cap> but some of them like the ports, start to look ugly in  amap
18:06:48 <hub_cap> but the part that snowdust didnt do was the autoloading
18:07:01 <hub_cap> i think it hsould be based on the datasotres that you have "installed", aka the ones in the database
18:07:05 <hub_cap> not based on yet another config
18:07:13 <hub_cap> if you don tdeploy couch, dont load its options
18:07:30 <hub_cap> does that make sense? should be perty easy to get that list from the db and autoload based on that
18:07:43 <robertmyers> could these be in the capabilities BP?
18:07:50 <amrith> hub_cap, that was a little different from what I was proposing in my bp
18:07:52 <hub_cap> robertmyers: some of them yes
18:08:04 <hub_cap> amrith: sure thats like a first step (what im tlkin about)
18:08:27 <hub_cap> robertmyers: im not sure that, say, ports for a given datastore need to be in capabilities
18:08:35 <hub_cap> root_on_create, i think yes
18:08:43 <robertmyers> ok
18:09:01 <hub_cap> and yes i know this is less of amirths and more of snowdusts work, and what ive done last wk
18:09:07 <SlickNik> I agree. I think the ports don't make sense in capabilities.
18:09:10 <hub_cap> but i think we can move forward w/ some of the autoloading
18:09:12 <amrith> so hub_cap, looks like we have to align our thoughts on this, maybe we can get it ready for discussion next week?
18:09:14 <hub_cap> and the configuration stuff
18:09:17 <hub_cap> yea i think so amrith
18:09:23 <hub_cap> its perty big
18:09:30 <amrith> SlickNik: action is mine to follow up with hub_cap
18:09:31 <hub_cap> might even be a summit talk
18:10:07 <SlickNik> Okay, let's table this until next week.
18:10:08 <amrith> hub_cap/SlickNik, I agree. the thrust of my idea is around eliminating duplicated code and there are many places where we are magically defining the same constants
18:10:13 <amrith> thx
18:10:19 <hub_cap> yup amrith ++
18:10:44 <SlickNik> amrith: Sounds good.
18:10:49 <SlickNik> #topic Adding datastore and version to the backup API
18:11:01 <SlickNik> robertmyers, all yours
18:11:03 <hub_cap> lol that doenst work here ;) but u konw that
18:11:04 <hub_cap> hehe
18:11:15 <robertmyers> sure
18:11:34 <robertmyers> basically we want to add the datastore to the backup api
18:11:39 <SlickNik> Yeah, I know :). I was surprised that meetbot actually responded earlier.
18:12:03 <robertmyers> I see amcrn had some comments?
18:12:39 <SlickNik> #link https://wiki.openstack.org/wiki/Trove/backup-metadata
18:12:53 <SlickNik> Yes, there's a couple of comments from him at the bottom of that page.
18:13:04 <esmute> robertmyers: As part of https://blueprints.launchpad.net/trove/+spec/cross-region-backup-availability, i am adding datastore and version to the backup table
18:13:25 <esmute> i am not changing the backup API nor the views to return them though
18:13:52 <esmute> perhaps we can work on this in a way we dont step on each other
18:13:57 <robertmyers> Well, the point is for someone to be able to tell what datastore was backed up
18:14:10 <robertmyers> SO my BP is to change the view
18:15:14 <esmute> i will make a change where the datastore is stored in the DB when a backup is started
18:15:14 <robertmyers> esmute: I'm fine with killing this if you do that as well
18:15:23 <amrith> robertmyers, is the version already in someplace and your bp is just to add it to the api?
18:15:43 <robertmyers> amrith: no, this will add it to the DB
18:15:43 <hub_cap> ir confused a bit
18:15:50 <hub_cap> dont u already know the datastore basd on the backup?
18:15:57 <robertmyers> hub_cap: no
18:15:58 <esmute> ok.. ill take this since i sorta started it.. i'll be syncing with you to make sure it covers what you had in mind
18:16:00 <hub_cap> sure change the view, but isint it tied to an instance, aka, u can generate it
18:16:13 <hub_cap> i dont know if we need to "store it" right?
18:16:28 <hub_cap> or is there no link to an instnace from a backup
18:16:37 <robertmyers> well, if you delete the instance then the info is gone
18:16:42 <hub_cap> is it?
18:16:46 <esmute> hub_cap: it is tied to the instance. Even if the instance is deleted, the we can find the datastore by querying the soft deleted instance
18:16:47 <hub_cap> or is it just DELETED=true
18:16:55 <hub_cap> right esmute
18:17:00 <hub_cap> id rather _not_ dup the storage
18:17:02 <robertmyers> we should not use soft deletes
18:17:03 <esmute> but the issue comes when a backup is copy from a different region (see my BP)
18:17:05 <hub_cap> if ew can just pull it
18:17:12 <hub_cap> robertmyers: ummmm i sure hope yer jokin ;)
18:17:18 <robertmyers> hub_cap: no
18:17:24 <robertmyers> delete it gone
18:17:34 <hub_cap> lol ok robert-conway
18:17:44 <amrith> esmute, has a use case where we must store the version
18:17:50 <robertmyers> hey the user requested a delete honor it
18:18:00 <robertmyers> :)
18:18:05 <hub_cap> smh robertmyers ;)
18:18:05 <amcrn> considering the underlying datastore-version will be changing on the instance when migrations land, having the current datastore-version isn't useful in determining the datastore-version that the backup was spawned from.
18:18:32 <esmute> amrith: Yes. when the backup is copied from a different region, there is no instances (active or deleted) that trove can query to find its datastore
18:18:34 <hub_cap> i think thats valid amrith
18:18:45 <esmute> nor its backuptype... but that is a different story
18:18:51 <amrith> and add to that amcrn's clarification
18:19:07 <amrith> seems like it is decided that we must store the datastore version; am I correct?
18:19:11 <esmute> amcrn: at least we need to know the datastore name.
18:19:31 <esmute> *know=store
18:19:31 <amrith> esmute, ok make that datastore name and version
18:19:36 <amcrn> see my question/comment on the wiki; you need the datastore-version + more.
18:19:38 <vipul> esmute: there won't be a backup in the new region either.. so how does a FKEY help you
18:19:56 <robertmyers> amcrn: but if the instance changes version the old backup will still be the old version?
18:19:58 <esmute> vipul: through the datastore version name
18:20:11 <vipul> which you provide in the api esmute?
18:20:14 <esmute> im hoping the datastore version name is unique :P
18:20:34 <esmute> vipul: nop.. it will be stored in the swift metadata
18:21:01 <amcrn> robertmyers: the backup row in the table should always know the exact datastore-version from which is spawned, regardless of whether the instance has moved on.
18:21:17 <amcrn> which it was spawned*
18:21:18 <cp16net> amcrn: +1
18:21:25 <robertmyers> amcrn: I agree
18:21:54 <robertmyers> which is why I think we should add a row or two to the backup table
18:22:04 <esmute> +1 robertmyers
18:22:19 <cp16net> robertmyers: dont you mean column?
18:22:23 <amrith> robertmyers, "a row or two"?
18:22:26 <esmute> if not the version, at least the datastore name..
18:22:30 <robertmyers> or three
18:22:37 <amrith> columns, maybe
18:22:40 <amcrn> can someone address my point in the wiki about backup/restore strategy?
18:22:41 <cp16net> :-P
18:22:44 <robertmyers> cp16net: +1
18:22:49 <kevinconway> we should have a column table where we can insert rows
18:23:25 <SlickNik> Yeah, I agree that we need to store this with the backup. Do we need to store the strategy as well?
18:23:30 <robertmyers> amcrn: well, I wasn't planning on changing the restore with this BP
18:23:35 <hub_cap> version uuid, ya?
18:23:38 <hub_cap> thatll give u all u need
18:23:43 <amrith> amcrn, if I understand your comment correctly, just name and version are insufficient; there is additional payload that is required.
18:23:45 <robertmyers> this is just to store the data for future use
18:23:46 <amrith> is that correct?
18:23:50 <amcrn> amrith: correct
18:23:55 <hub_cap> FUTURE PROOF robertmyers
18:24:00 <esmute> lol
18:24:27 <SlickNik> hub_cap: version_uuid, probably yes.
18:24:32 <esmute> robertmyers: +1. Restore wont be changed
18:24:40 <hub_cap> yup SlickNik thats all u need
18:24:54 <cp16net> #agree
18:24:59 <esmute> ok so yes to adding datastore to backup records?
18:25:15 <amcrn> i guess we're not going to address the fact that the strategy can change at any time, and you'll have backups blowing up.
18:25:16 <cp16net> #info just need to add the version_uuid to the backup table
18:25:36 <robertmyers> amcrn: that seems like a new BP
18:25:54 <amcrn> let me tl;dr my point: store datastore-version-uuid + backup/restore strategy in 3 columns.
18:26:15 <robertmyers> amcrn: okay 3 columns it is
18:26:24 <hub_cap> eww i see yer point, but eww amcrn
18:26:30 <kevinconway> make it four and you have a deal
18:26:47 <amrith> amcrn, why do you need backup_strategy in the backup? shouldn't restore strategy suffice?
18:26:49 <hub_cap> kevinconway: one row default="troll", sound good?
18:26:59 <esmute> amcrn: so storing the dataversion-uuid and the type?
18:27:01 <SlickNik> amcrn: wait what's the 3rd. I understand version_uuid, backup_strategy…and?
18:27:24 <amcrn> SlickNik: restore_strategy
18:27:27 <kevinconway> hub_cap: we can put a hash index on it for super fast lookups
18:27:34 <robertmyers> we already have the backup type
18:27:48 <esmute> this is what i have so far
18:27:49 <esmute> https://gist.github.com/anonymous/11151670
18:27:58 <amrith> amcrn, why do you need backup_strategy in the backup? shouldn't restore strategy suffice?
18:28:12 <SlickNik> robertmyers: Oh yeah, I thought we had something.
18:28:15 <hub_cap> kevinconway: ;)
18:28:43 <amcrn> amrith: with a datastore with two competing backup_strategy's, you can't possibly know which one was used if the deployer has flipped between the two at any point in time
18:28:50 <robertmyers> so the restore uses the backup type to look up the restore strategy
18:28:57 <hub_cap> maybe the version should have a backup/restore strat
18:29:02 <hub_cap> and we shouldnt allow a change inflight
18:29:09 <hub_cap> aka once u set it in the version table, its done
18:29:18 <hub_cap> for all of that version
18:29:21 <kevinconway> do we have plans to offer multiple backup/restore strategies per dstore?
18:29:23 <amcrn> hub_cap: that's another way to do it
18:29:29 <vipul> hub_cap: +1 i don't see changing a backup strategy is something you should do
18:29:35 <hub_cap> well it might be
18:29:38 <hub_cap> but not in the same version
18:29:42 <grapex> hub_cap: That's too limiting- what if people want to backup a datastore in multiple ways?
18:29:49 <amrith> kevinconway: I believe not. hence my question.
18:29:53 <grapex> In case there's an improvement that comes around
18:29:57 <hub_cap> grapex: who is people?
18:30:00 <hub_cap> operators?
18:30:03 <grapex> Yeah
18:30:07 <grapex> today we use xtrabackup
18:30:15 <cp16net> maybe i want a mysqldump of my database to put it somewhere else and a xtrabackup all the other times
18:30:18 <robertmyers> ok, i think this has been going on for a little too long now
18:30:19 <grapex> what if super xtra backup gets released tomorrow and is incompatable
18:30:21 <juice> grapex: +1
18:30:22 <SlickNik> Okay, so let's do this. We all agree on the version_uuid.
18:30:36 <hub_cap> yes seems like the other thing is a spiral at present SlickNik
18:30:45 <esmute> We can store the strategy in the swift metadata? So when the restore is being done, it reads this metadata and knows which strategy to use?
18:30:48 <juice> I can see a case where the strategy has been changed and you have an old backup with the prior strategy that you want to restore
18:30:53 <amrith> amcrn, if a backup is with xtrabackup then there's only one way to restore it. similarly if it is a snapshot there's only one (different) way to restore it
18:30:57 <SlickNik> And we need some more definition around the multi backup-restore strategy case.
18:30:59 <amcrn> juice: my point exactly
18:30:59 <hub_cap> esmute: thats sane i think
18:31:03 <juice> esmute: that works too
18:31:11 <amrith> so, I'd suspect that for a given backup, storing just the restore strategy should suffice.
18:31:21 <juice> the only requirement is to store the strategy along with the backup
18:31:31 <juice> whether that is in the database or the swift object does it matter?
18:31:34 <vipul> so theoretically if a backup occurred with xtrabackup 2.1 .. it shoudl be restorable with xtrabackup 2.2
18:31:34 <SlickNik> So let's approve this BP, and incrementally add the other case as part of another bp.
18:31:35 <hub_cap> id also suspect that this really wont change a ton in general
18:31:36 <kevinconway> so i think this convo has gone way outside the scope of the BP
18:31:41 <vipul> are we saying that we can only use 2.1 restore?
18:31:47 <juice> perhaps in esmute's scenario where you have cross region backups/restore
18:31:50 <hub_cap> juice: its not something we need to store, its redundant, and will eventually help clog our db
18:31:53 <hub_cap> :)
18:32:02 <hub_cap> the app only needs to know about it on restore
18:32:02 <esmute> SlickNik: +1
18:32:10 <SlickNik> I'm calling time on this one, for now. :)
18:32:14 <hub_cap> kevinconway: ++ its a spiral
18:32:20 <robertmyers> SlickNik: +1
18:32:23 <amcrn> we can approve the uuid only, the point was to dispell the rumor/idea that somehow it was sufficient
18:32:27 <esmute> we need backup to store datasstore information... we can add the other stuff incrementally
18:32:28 <amcrn> for all use-cases
18:32:41 * hub_cap hands amcrn a wrench
18:33:01 <kevinconway> you could always convert the version_uuid field to a json blob that contains all the other metadata later
18:33:03 <juice> esmute: storing it in the metadata seems like a logical approach
18:33:07 <SlickNik> amcrn: I think we need to still discuss the other case. But later. :)
18:33:12 <SlickNik> I want to hear about:
18:33:14 <amcrn> k
18:33:19 <SlickNik> #topic Move the Trove Guest Agent to its own module
18:33:21 <hub_cap> dont feed the kevinconway
18:33:36 <robertmyers> #link https://wiki.openstack.org/wiki/Trove/MoveTroveGuest
18:33:42 <robertmyers> lets do it
18:34:07 <vgnbkr> Given the impact to other bps/bugs, could it be fasttracked?
18:34:17 <robertmyers> the idea here is a baby step before moving to a separate repo
18:34:35 <hub_cap> I LIKE IT
18:34:46 <hub_cap> way better than tryin to rip it out wholesale
18:34:47 <esmute> robertmyers: will trove-common be part of the guest-agent...similar to openstack-common?
18:35:06 <robertmyers> esmute: it will need some oslo stuff
18:35:22 <robertmyers> but for now the plan was just to copy it in plave
18:35:25 <robertmyers> place
18:35:49 <robertmyers> once it is in a new repo it will have its own oslo and config
18:36:05 <cp16net> this sounds like a good idea
18:36:20 <esmute> cool
18:37:00 <juice> robertmyers: this is a good approach +1
18:37:14 <SlickNik> robertmyers: I'm totally on board with this.
18:37:20 <grapex> +1
18:37:35 * cp16net pushes the easy button...
18:37:36 <robertmyers> SlickNik: juice: cool
18:37:52 <robertmyers> hahaha
18:37:54 <SlickNik> Approved. All agree?
18:37:56 <esp> cp16net: :)
18:38:04 <amrith> agreed: +1
18:38:16 <annashen> guest agent finally gets its own nest
18:38:18 <cp16net> esp: i really did...
18:38:18 <cp16net> :-P
18:38:36 <SlickNik> robertmyers: Any ideas for the timeline? Trying to address vgnbkr's comment about whether the change would be disruptive...
18:38:59 <SlickNik> and whether we need to get this in asap.
18:39:04 <robertmyers> Well, I can put the review up by the end of the week
18:39:17 <kevinconway> what disruption do you expect? a copy/pasta into another dir shouldn't be too bad of a rebase
18:39:51 <robertmyers> basically once this is approved (the reivew) it needs to be merged first
18:39:53 <grapex> kevinconway: Eeeh, it will and it won't
18:40:21 <grapex> I think we should prioritize moving it though
18:40:21 <SlickNik> kevinconway: There's _always_ little things.
18:40:30 <grapex> it will make reviewing guest agent pull requests much easier
18:40:34 <grapex> and we will stop making stupid mistakes
18:40:37 <SlickNik> robertmyers: done, go forth and do it.
18:40:46 <robertmyers> SlickNik: ok
18:40:56 <SlickNik> And thanks! :)
18:40:58 <esmute> grapex: not so sure about your second point
18:41:11 <SlickNik> #topic Database log files manipulations
18:41:22 <SlickNik> denis_makagon?
18:41:24 <kevinconway> this sounds sinister
18:41:41 <grapex> kevinconway: The original title was "log file machinations"
18:41:42 <esmute> going once :P
18:41:59 <amrith> I'd +1 with that old title
18:42:17 <amrith> SlickNik: question
18:42:28 <amrith> the BP is set to "Needs Code Review", is that accurate?
18:42:38 <amrith> or is the BP in need of review/approval?
18:42:49 <SlickNik> amrith: I think that there was a gerrit patch submitted for it.
18:43:04 <amrith> several as a matter of fact
18:43:06 <openstackgerrit> Doug Shelley proposed a change to openstack/trove: Correct inconsistent state issues with config  https://review.openstack.org/88591
18:43:09 <SlickNik> amrith: and gerrit updates the bp status automatically based on the Commit Message.
18:43:18 <amrith> ok, I get it
18:43:20 <hub_cap> SlickNik: ?
18:43:27 <SlickNik> LEt's move on.
18:43:29 <hub_cap> did they impl that? cuz i used to do it manually
18:43:38 <hub_cap> aka gerrit does bugs but it dindt used to do bps
18:44:35 <SlickNik> hub_cap: The "code review" piece has worked for me, not the "Committed" piece.
18:44:45 <hub_cap> k
18:44:50 <SlickNik> But it's been flakey, not sure why.
18:45:01 <SlickNik> Next one is denis' too.
18:45:09 <SlickNik> So let's table that till he's around.
18:45:18 <SlickNik> #topic Add backup and restore support for single instance couchbase
18:45:33 <hub_cap> oh this is a terrible idea
18:45:38 <hub_cap> kidddddding
18:45:41 <michael-yu> SlickNik - i added this one. but i think forgot to put my name
18:45:47 <michael-yu> hup_cap: :)
18:45:48 <hub_cap> do we really neeed to discuss this? i mean, yes we need it, approved
18:45:51 <esmute> SlickNik: hub_cap spoke. Lets move on :P
18:46:25 <SlickNik> I'm good with this.
18:46:33 <SlickNik> We need to do it. Approved.
18:46:35 <amrith> before you approve it, does it make sense to ensure it is aligned with others that are already doing b&r
18:46:42 <amrith> too late.
18:46:55 <robertmyers> amrith: I think the review can handle that
18:47:10 <amrith> robertmyers, code review?
18:47:14 <robertmyers> amrith: yes
18:47:17 <hub_cap> robertmyers: ++
18:47:21 <amrith> next!
18:47:27 <hub_cap> its pertty straight forward :)
18:47:42 <SlickNik> #topic Populate endpoint URLs from Keystone service catalog
18:47:52 <SlickNik> esmute: your up.
18:47:58 <SlickNik> you're*
18:48:02 <esmute> well.. the point is simple.. To remove the openstack endpoints from the config and get these URL from keystone catalog
18:48:11 <kevinconway> i have a concern with this one
18:48:23 <robertmyers> esmute: +1
18:48:24 <kevinconway> the BP says you are removing the config options
18:48:24 <esmute> what is it kevinconway?
18:48:32 <SlickNik> IIRC, matt lowery was trying to do something similar (and had a review for it at some point too, I think).
18:48:35 <kevinconway> so this is backwards incompatible?
18:48:39 <hub_cap> yea mat-lowery had done this
18:48:41 <mat-lowery> There's a patch set for this https://review.openstack.org/#/c/68015/
18:48:45 <mat-lowery> :)
18:48:50 <hub_cap> i think mat-lowery 's work was valid too
18:48:56 <esmute> you can have the config there but it wont be read by trove
18:48:58 <hub_cap> even w/ its order of how it retireved
18:49:04 <hub_cap> *retrieved
18:49:10 <esmute> ahh i didnt know about that patch mat-lowery
18:49:15 <hub_cap> mat-lowery: correct me, but if there is a config it overrides the service catalot right?
18:49:29 <mat-lowery> correct...the default (in the patch) is to get from catalog
18:49:51 <esmute> ok.. i can abandon my BP and use mat-lowery's patch
18:49:52 <hub_cap> wait thats the opposite of what i said hehe
18:49:57 <hub_cap> yes esmute
18:49:59 <vipul> yea i think the default is get from conf
18:50:03 <vipul> according to the patch
18:50:05 <hub_cap> yes i thought so to vipul
18:50:13 <hub_cap> i think it was originally the opposite but we whined
18:50:42 <robertmyers> as long as we can still override it when needed I'm fine with it
18:50:43 <vipul> yep, looks much better mat-lowery, sorry it's been waiting in the review state for so long :(
18:50:48 <mat-lowery> if *_url in conf, use it else use catalog
18:50:50 <grapex> robertmyers: ditto
18:51:10 <grapex> Here at Rax, especially in staging and other environments we don't always have the luxury of using the catalog.
18:51:27 <cp16net> yup
18:51:32 <hub_cap> grapex: its more likely we can use the sears catalog than our service catalog in staging
18:51:38 <grapex> hub_cap: LOL!
18:51:46 <robertmyers> hub_cap: lol
18:51:57 <SlickNik> mat-lowery: Looks good at first glance. Will review it later this afternoon.
18:52:07 <mat-lowery> ok thanks
18:52:22 <kevinconway> so that's awesome that mat-lowery made the thing backwards compat
18:52:23 <hub_cap> esmute: plz give some review to it as well, to make sure it meets your needs
18:52:29 <kevinconway> but does core have an official stance on how we plan to deprecate config options on occasions like this?
18:52:34 <esmute> will do hub_cap. Thanks
18:52:43 <grapex> kevinconway: I don't see why we need to deprecate them
18:52:49 <hub_cap> kevinconway: i think its an openstak thing, like a N+1 strategy
18:52:49 <grapex> I think the service catalog is great, if it works
18:52:53 <robertmyers> kevinconway: it does not deprecate them
18:52:55 <hub_cap> but for this it wont deprecate
18:52:57 <SlickNik> kevinconway: I think they're still supported. Just optional.
18:52:58 <grapex> but there's plenty of times you may need to override it
18:53:05 <kevinconway> SlickNik: that's deprecated
18:53:15 <robertmyers> kevinconway: ?
18:53:16 <kevinconway> eventually they would be removed, yes?
18:53:20 <hub_cap> no thats optional
18:53:22 <vipul> i hope not
18:53:24 <grapex> like if you're trying to boot strap Trove in a vacuum, and maybe keystone or anything like it isn't set up
18:53:27 <robertmyers> kevinconway: never
18:53:27 <hub_cap> eventually removed is deprecated
18:53:27 <kevinconway> deprecated doesn't mean gone
18:53:30 <SlickNik> kevinconway: They're not going away.
18:53:31 <hub_cap> optional is optional
18:53:39 <kevinconway> ok so diamonds are forever?
18:53:44 <hub_cap> some orgs will always use those optional configs
18:53:56 <hub_cap> we will deprecate and remove non heat support for installs
18:53:58 <grapex> kevinconway: Yes, just consider that we've gone with diamond mode
18:54:05 <SlickNik> Time to move on I think. :)
18:54:14 <SlickNik> #topic Enable specification of Cinder Volume Types
18:54:19 <SlickNik> So this one is mine.
18:55:10 <SlickNik> And it's an addition to the conf file to specify the volume_type to use when provisioning a cinder volume.
18:55:27 <vgnbkr> SlickNik : I get a message that your page is private for the wiki.
18:55:34 <SlickNik> I'm still drafting this, so I just wanted to get feedback on what people thought.
18:55:37 <grapex> I like this idea
18:55:55 <grapex> it should probably become a capability though so we can pick them for each datastore type
18:55:57 <SlickNik> vgnbkr: The wiki's still not there. So it's still drafting.
18:56:01 <vipul> SlickNik: at some point we want to tie this to datastore version?
18:56:01 <vgnbkr> SlickNik: oh, nevermind - I didn't read the link, just clicked on it :-)
18:56:07 <vipul> grapex: +1
18:56:26 <SlickNik> grapex: Yes that's the reason it's still drafting. I'm thinking about whether we should add this to capabilities when we that's added.
18:56:55 <hub_cap> yea we need ot fasttrack capabilities
18:57:04 <hub_cap> since we have other things that "maybe one day will be a capability"
18:57:09 <grapex> imsplitbit: Spare thee not the whip!
18:57:21 <hub_cap> i think k-pom has a review up
18:57:25 <hub_cap> so maybe imsplitbit needs to whip us ;)
18:57:29 <SlickNik> Okay, I have the feedback I was looking for.
18:57:34 <kevinconway> where there's a whip there's a way!
18:57:45 <hub_cap> exactly kevinconway
18:57:51 <grapex> hub_cap: hopefully not Peter Griffith style
18:57:54 <grapex> kevinconway: lol
18:58:05 <SlickNik> +1 on getting capabilities in soon.
18:58:15 <SlickNik> I think that's all we have time for.
18:58:19 <SlickNik> #endmeeting