18:00:32 #startmeeting trove 18:00:33 Meeting started Wed Mar 4 18:00:32 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:37 The meeting name has been set to 'trove' 18:00:37 o/ 18:00:41 o/ 18:00:46 o/ 18:00:48 o/ 18:01:01 o/ 18:01:07 o/ 18:01:21 hello @all 18:01:23 Agenda at: 18:01:24 o/ 18:01:26 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:01:27 o/ 18:01:39 o/ 18:01:45 #topic Trove pulse update 18:02:01 #link https://etherpad.openstack.org/p/trove-pulse-update 18:02:28 o/ 18:02:38 o/ 18:02:44 Looks like we had fewer reviews done this week. 18:02:57 We also had fewer uploaded patchsets. 18:03:32 My suspicion is we have less overall new reviews this week and the reviews that are up are large blueprints and large changes 18:03:40 Thanks to all the folks who did reviews! 18:03:45 good point, edmondk 18:03:59 0/ 18:04:00 I think at this point, we really need to start looking through the large reviews. 18:04:03 The blue prints just take a considerable longer time to review 18:04:25 Given how close we are to feature proposal freeze and feature freeze. 18:04:40 So we need to keep reviewing, and keep the momentum up! 18:04:44 o/ 18:05:39 Another point is that we've cleaned up our total review count pretty nicely. 18:05:52 total open review count* 18:06:06 what was it last week 18:06:08 or the week before 18:06:11 We're down to 37 from 58 last week. 18:06:15 nice 18:06:38 thats really a nice update 18:06:41 that's cool :) 18:07:06 Okay, more work to be done with reviews — let's keep the momentum going! 18:07:26 Any other questions / clarifications? 18:07:43 . 18:07:49 #topic Feature proposal freeze at the end of this week. 18:08:15 So we have a few api-specs that aren't merged yet. 18:08:27 Some are waiting on reviews, and others on updates from the submitter. 18:09:02 This week is Feature Proposal Freeze across OpenStack — so after this week, you'd need an exception to add a BP for the Kilo release. 18:09:13 The list of open specs is at: https://review.openstack.org/#/q/status:open+project:openstack/trove-specs,n,z 18:09:32 I'd encourage everyone to make reviewing those a top priority. 18:10:08 Are all these specs (well, the code for the specs) expected to make it into Kilo? 18:12:18 dougshelley66: Yes, all of those were being targeted for kilo. I'm not sure if all of them are still on track to make it into kilo. I've seen reviews for some of them but not others. 18:12:48 I've just pushed a change to the replication spec to reflect Iccha's comment (I removed 2 lines). If everyone could +1 again who did so before, that would be great. 18:13:17 dougshelley66: But the api-spec being reviewed and merged is a requisite for the code to be merged in kilo. 18:14:01 SlickNik, understood, thanks 18:15:11 I'm going to spend some time looking at the reviews for the specs today as well. 18:15:33 Any questions regarding this? 18:15:54 . 18:16:02 #topic SSH keys injection on Trove instance creation 18:16:18 that's mine 18:16:27 so, I dunno if this is the best moment to discuss about it 18:16:52 vkmc: I don't see why not. 18:17:13 but I wanted to ask if this feature has been discussed before and if you all think we could add it 18:18:06 vkmc: if I recall correctly this did come up once before — folks were of the opinion that since you actually baked the guest image you have the option of injecting the key directly in the image. 18:18:08 I would personally love the feature for development 18:18:55 vkmc: But I can see the argument that having a key injected at boot time could certain dynamic scenarios. 18:18:56 SlickNik, yeah, that is true... but baking the key directly in the image forces you to stick with the same key for every single instance you launch with that image 18:19:07 could enable* 18:19:21 So I think there's a use case here that needs to be fleshed out. 18:19:56 Perhaps a good option for a new blue print? 18:20:01 so we have functoinality like this in our product 18:20:03 It's just wrapping nova's implementation I would assume 18:20:04 sure :) 18:20:11 edmondk, exactly! 18:20:16 it shouldn't be hard to add 18:20:23 on the nova_client.servers.create in task manager 18:20:24 would you like to konw what we did? 18:20:32 and it would make debugging why an vm failed, for instance, easier 18:20:42 dougshelley66, of course! 18:20:45 dougshelley66: yes 18:20:57 so we added a taskmanager.conf key - use_nova_key_name 18:21:09 this is the name of a nova keypair that gets injected during trove create 18:21:35 if you also open port 22 in the tcp_ports section for the datastore, then you can ssh straight in after boot 18:22:11 injected is probably the wrong word - we paas it in on nova boot via the --keyname option 18:22:34 yeah, true that 18:22:39 dougshelley66: got it. That has assumptions about deployment methodology (like there being a keypair by that name in the tenant that the instance is deployed to) 18:22:48 So if you want to use a different key, all you have to do is delete the nova key and import a new one with the same name 18:22:56 SlickNik, yes 18:23:25 why not just add another paramater to trove create for keyname? 18:23:26 it works very well for the debugging use case 18:23:27 would probably need to think through this in the BP/spec as well. 18:23:29 should take about 20 minutes 18:23:55 then also have to add it to troveclient etc 18:23:57 so on trove create would allow the end user to do it 18:24:07 i don't believe we want that 18:24:08 yes just like a user can also nova boot with a keyname 18:24:14 end user shouldn't be able to ssh 18:24:18 I was actually confused why trove didn't already allow this 18:24:20 right - the question is whether we would want this as end user visible 18:24:36 ... or as a behind the scenes debugging tool 18:24:48 edmondk, nova boot and trove create are 2 totally different use cases 18:24:59 edmondk: That's not a scenario (SSH to trove instance) that we want to enable for end users since the trove instance is supposed to be a managed DB instance. 18:25:30 so it's more of a debugging / operator convenience to have something like this. 18:25:40 that is what we engineered it for 18:25:52 we could take a shot at a BP/spec if you like 18:26:45 Well, I'd suggest working with vkmc. 18:26:50 certainly 18:26:56 the end user is already allowed to nova delete their own trove instance? 18:27:06 sure, I'd like to make this feature land in Trove 18:27:20 i assume we are post-kilo at this point? 18:27:34 if the end user has access to do anything through nova commands to their trove instance, being able to ssh could possibly make sense 18:27:36 we could discuss about the use cases more thoroughly in a spec 18:27:38 we can do a bp/spec for liberty 18:28:03 dougshelley66, sounds good! 18:28:05 dougshelley66: Yes, unless you wanted to get a spec up in the next 3 days. :) 18:28:10 which I don't recommend. 18:28:37 edmondk: Operators don't give trove users access to the nova endpoints. 18:29:26 edmondk: in devstack you do, but that's because it's devstack. 18:29:58 Okay, we have a clear path forward for this. Let's move on. 18:30:09 sure, thanks all 18:30:13 #topic Review 131610 18:30:32 #link https://review.openstack.org/#/c/131610/ 18:30:40 shouldn't that item have some more description aroudn it? 18:30:48 i.e. like the agenda guidelines state? 18:31:05 sorry for that 18:31:34 np just didn't understand what the goal was 18:32:15 so, that spec has been around for a long time now 18:32:19 X019_: I noticed the updates to the patchset — am planning to review specs today, so will take a look at the review. 18:32:40 just need someone to go through it and see if its ok 18:32:47 Is there a specific issue with it that needs to be discussed? 18:33:29 not that i know of 18:34:03 i think i covered pretty much everything from last time 18:34:13 X019_: Thanks for the update. 18:34:15 X019_: In general — we shy away from adding reviews as an agenda item to the meeting unless there's some contention, or a point of discussion that needs to be had. 18:34:38 Sounds good. 18:34:42 X019_, thanks for bringing it up, I have already reviewed it and I was going to submit some comments soon 18:34:46 #topic Open Discussion 18:35:09 I had one that's a follow up from last week. 18:35:34 SlickNik, ok i got it 18:35:58 X019_: Not a problem :) 18:36:38 Looks like we have a clear front-runner at http://doodle.com/candscrt36hg38a7 18:37:08 Week of Aug 24th for the Liberty Mid Cycle sprint 18:37:36 So I'm going to run with that date. 18:39:14 Any other items for open discussion? 18:39:43 not from me :) 18:40:10 We can end early, and folks can have a few minutes back in that case. 18:40:30 Remember to review the api-specs! 18:40:31 https://review.openstack.org/#/q/status:open+project:openstack/trove-specs,n,z 18:40:35 #endmeeting