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