17:59:42 #startmeeting trove-bp-review 17:59:43 Meeting started Mon Nov 24 17:59:42 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:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:47 The meeting name has been set to 'trove_bp_review' 18:00:11 Giving folks a few minutes to trickle in. 18:00:16 o/ 18:00:20 ./ 18:00:20 o/ 18:00:23 Agenda at: 18:00:25 #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting 18:00:41 o/ 18:01:13 hi vkmc 18:01:23 hi amrith! 18:01:48 #topic Switch Trove to use OSLO Messaging 18:01:58 #link https://review.openstack.org/#/c/136352/ 18:02:24 I put the BP up for this change set. the change has been around since the time of the great flood. 18:02:26 I rebased it yesterday and waiting for reviews 18:02:30 it would be good to get it merged. 18:03:27 the spec is a formality 18:03:39 as discussed at last BP meeting. 18:03:55 all projects going in for kilo cycle should have spec in RST/trove-specs 18:04:00 amrith: It's currently failing the gate specs-docs gate — so needs a few more changes? 18:04:03 this is just the old text from wiki in RST format. 18:04:10 I will look into that. 18:04:13 had not seen that. 18:04:14 o/ 18:04:45 i will fix that. 18:05:08 it is ironic that sergey can get oslo.messaging working and I can't get a spec to pass spec gate. 18:05:09 ;( 18:05:44 amrith, ironic is the name of component 18:05:51 Okay thanks. 18:05:56 o/ 18:06:11 o/ 18:06:26 SlickNik, looks straightforward. 18:07:02 This is pretty high on my list to get merged, so I'll look into as soon as it's good to go. 18:07:23 what do you mean good to go? 18:07:59 passing the specs-doc gate (like I mentioned earlier) 18:08:27 sgotliv: I think you need to merge it again ... :( 18:08:50 peterstac: I think you mean rebase it again 18:09:02 sgotliv: sorry, yes rebase 18:09:09 peterstac, thanks for reminding me :-) 18:09:30 rebase is my middle name 18:10:16 lol 18:10:35 sgotliv: if I can help if you get too tired :) 18:10:59 SlickNik, you can! Merge it :-) 18:11:42 Okay, anything else on this? 18:11:50 look, this patch is really big and probably will break something :-) but 18:11:55 I'm trying. 18:11:58 we have to merge it 18:12:53 for starters, could we get some more reviewers. I'm trying to run the code and finally got it (I think) working. 18:13:03 but my machine is badly messed up now. 18:13:05 with other crap 18:13:26 I'll to run it once the next rebase is done 18:13:36 I'm planning to take it for a spin as well. 18:13:37 I'll run it ... 18:13:53 Peter, I'll rebase it tonight 18:14:13 sgotliv: Ok, thx 18:14:30 sgotliv, isn't it already tonight :) 18:14:46 its still 20:15 here :-) 18:14:59 ah early...right 18:15:04 you've still got over 3 hours ;) 18:15:18 Okay, looks like there are no more questions on this. Let's move on to the next item. 18:15:36 #Topic Allow users to retrieve guest log files 18:15:54 #link https://review.openstack.org/#/c/131610/ 18:15:55 this one is (I think) passing jenkins 18:15:58 could we get it approved. 18:16:14 Also Anna got officially accepted in OPW program 18:16:22 thanks amrith for yoru work on the bp 18:16:26 *your 18:16:44 np, (though the work isn't yet "done") 18:16:48 till it gets merged 18:16:51 guys, from security perspective it might be an issue 18:17:21 how so? 18:17:39 and if that's the case, could you put the comments on the spec (apologies if you already did and I missed them). 18:17:54 I will 18:17:58 amrith: We need folks to review it. I have a concern with the BP as it stands — we're sending the whole log (which can be pretty big) over RPC. 18:18:03 yeah 18:18:15 and was wondering if u should limit/paginate it 18:18:16 how does nova do it with console-log? 18:19:05 re security: the slow query log could potentially expose ids from the database, or worse complex insert statements with user data 18:20:05 ok, 2 issues raised here. 18:20:06 amrith: Not sure off the top of my head — and the slow query log can grow much bigger than the console log. 18:20:07 1. size of log 18:20:11 2. security 18:20:26 re: size of log, there is an option for the user to specify ranges 18:20:34 in terms of line number from:to or a search parameter 18:20:43 that would allow the user to restrict the amount that was sent back. 18:20:50 what if the user is stupid enough not to use that? do we protect them against them own stupidity? 18:20:52 re: security, the access to the API could be controlled 18:21:03 I like senting it to swift containers 18:21:23 vs returning it via API 18:21:33 that is provided as an alternate implementation, I think. 18:22:05 personally, when you try to make something idiot proof nature creates a better idiot. 18:22:07 I wouldn't bother. 18:22:19 unix command lines give you the ability to retreive very large files 18:22:22 and you can process them., 18:22:30 through command line tools 18:22:40 filtering and limiting by line numbers seems like a good start 18:22:45 because doing it by time is not that easy 18:22:53 and not necessarily possible in all data stores. 18:23:00 but please put these comments on the review. 18:23:05 that is the point of having them in RST. 18:23:08 amrith: I disagree, I'm not sure sticking such a large message in rabbit is a good idea. I hear it does bad things to rabbitmq, especially if you run in a clustered configuration. 18:24:39 Yes, will put these comments in the rst. 18:24:47 ok, so since we're discussing this at the meeting. 18:24:52 should we just vote for the swift option 18:24:54 I don't like it 18:25:01 but I'd like this to move forward. 18:25:56 About the bp, I noticed that the rest APIs aren't called out. I'm not sure if that's supposed to be the standard? 18:26:06 amrith proposed openstack/trove-specs: Switch Trove to use OSLO Messaging. https://review.openstack.org/136352 18:26:29 I'm sure we'd all like our specs to move forward :) 18:26:31 I didn't know that it was a standard but yes, the API's and responses are not provided. 18:27:26 iccha, now that anna is here does it make sense for her to take this over and enjoy the fun (sorry, experience). 18:28:11 amrith: yes I think it will be good experience for her to go through the process end to end 18:28:17 anna_: u around? 18:28:32 yes 18:29:18 vgnbkr, sgotliv, SlickNik, iccha please put your comments into the review. 18:29:20 Please feel to leave comments on the review and anna_ and I will discuss it and anna_ can submit future iterations 18:29:21 So what is the swift option, what does the API for that look like and how is it different? I'm not sure what we'd be voting on during this meeting. 18:29:21 I think laying those details down in the spec and having folks comment on it would make more sense. 18:29:43 iccha / anna_: +1 18:30:09 SlickNik, the API from the request perspective would look the same (I think). The result would be that a file got dropped on swift and the response potentially included a name. 18:31:02 unless you want to eliminate the parameters (line number range and match) and always push the full file. 18:33:36 Would we have an equivalent clean up API? Or would it be up to the user to delete the file out-of-band? 18:33:48 Just some questions I had — probably best to take it to the spec. 18:33:49 o/ 18:34:12 SlickNik: deleting log file on instance? 18:34:21 yeah lets discuss it in spec 18:34:34 iccha, not a good idea to delete log files on the instance remotely 18:34:37 iccha: in swift — sounds good. 18:34:41 ok, let's discuss in spec. 18:35:17 #Topic Add instance name as parameter to various CLI commands 18:35:19 I agree with amrith, sounds like troubles 18:35:33 yup me too 18:36:13 so I added this to the agenda, doug submitted the spec. 18:36:19 i'm here 18:36:20 I see that some people have reviewed it. 18:36:22 FWIW, I'm leaning towards letting the user clean the file up from swift (out-of-band) as well. 18:36:25 ah ... 18:36:29 dougshelley66, go ahead. 18:36:47 as amrith mentioned, the spec has had some reviews 18:37:12 is there anything anyone wants to ask about it 18:38:29 Seems fairly straightforward — I had just one comment on it this morning (some confusion regarding the Public API) — looks like it's been addressed. 18:38:31 Thanks dougshelley66 18:38:45 np 18:40:13 so does the BP still need to get approved? 18:40:36 On a related note, and maybe the subject of open discussion later. 18:40:37 My question is about the goal of this meeting. When BP's were on wiki, this was THE place to discuss them. I've been looking to this meeting as the place where BP's are approved but that may be incorect. Now that BP's are on gerritt, the discussion can happen there and each BP need not come to this meeting. So, I'm asking what the purpose is for this meeting. 18:41:08 Yes, dougshelley66 — the approval of the BP happens offline, using the same process for code reviews (i.e. two +2's and an approved) 18:41:35 SlickNik, i was asking about the LaunchPad BP 18:42:27 Once the spec is approved, I'll go ahead and update the launchpad bp as well. 18:42:41 Feel free to set the milestone-target as appropriate. 18:42:55 SlickNik, great thanks 18:43:02 amrith, that's why I suggested earlier that the agenda should be published days before the meeting, so that people have already reviewed them. If items can be added up to the start of the meeting, people will not have seen them to comment inline and will discuss in the meeting. 18:43:32 amrith: It's for folks to talk about BP's and give them some visibility. 18:44:09 ok (to both of you, vgnbkr and SlickNik). it isn't a 'requirement' that all BP's come up here 18:44:20 if they are dealt with in gerritt, I guess. 18:44:21 thx 18:44:30 It is _not_ a requirement for BPs to come to this meeting. 18:44:46 Also, if folks feel that the meeting isn't very useful, since we're now doing our BP reviews out of band anyway — I'm totally up for not having it any longer. 18:45:21 +0.5 18:46:35 Maybe (since it presumably won't take as much time) it could be rolled back into the Wed meeting if needed ... 18:46:56 My view was to keep it going for a couple of weeks, and see how the discussions progress and how it evolves before making a call. 18:47:19 OK, I'll revise my vote. +0.25 18:47:47 peterstac: +1 18:47:53 Perhaps we should try that. 18:48:13 And we can move to a separate meeting again if that gets out of hand. 18:49:24 I suggest that bps can only be discussed on wednesday if they were in the agenda by monday so that people have had a chance to review them. 18:49:53 vgnbkr, I think the idea was that there would be no agenda for monday 18:49:56 Okay will put together a proposal for discussion during our Wednesday meeting. 18:50:02 but that doesn't solve the problem you raised. 18:50:36 amrith, no meeting on monday, but still publish an agenda so people know what's upcoming and needs review. 18:51:03 amrith / vgnbkr: That would be a problem iff you wanted folks to vote on a BP during the meeting. If we're doing it out of band, is there still a requirement to having read the BP entirely before the meeting? 18:51:28 Let's continue this discussion out of the meeting. 18:51:35 k 18:51:35 That's all we had for the agenda for this week. 18:51:38 Thanks folks! 18:51:41 #endmeeting