17:59:10 #startmeeting Trove 17:59:11 Meeting started Wed May 27 17:59:10 2015 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:15 The meeting name has been set to 'trove' 17:59:47 o/ 17:59:53 o/ 17:59:59 Hello and welcome back from the Summit! 18:00:03 o/ 18:00:04 hello :) 18:00:20 Meeting agenda for today is at: 18:00:22 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:00:37 *\o/* 18:00:59 o/ 18:01:01 Quite a busy agenda for today. 18:01:09 o/ 18:01:10 ./ 18:01:17 #topic Trove pulse update 18:01:27 #link https://etherpad.openstack.org/p/trove-pulse-update 18:01:37 o/ 18:02:28 o/ 18:02:34 o/ 18:02:55 o/ 18:02:56 Looks like we're still pulling in ~100 reviews a week. 18:02:59 o/ 18:04:01 A lot more patches coming in — I see that Total Open Reviews number going up to ~46 now. 18:04:52 \o/ 18:05:04 Lots of activity after the summit! 18:05:24 Let's move on — a lot to cover this meeting. :) 18:05:25 i think victoria wants to say something ;) 18:05:31 yeah, there's still a fair number of specs that need review 18:05:32 Go for it, vkmc 18:05:48 haha no, I'm celebrating for the progress after summit :) 18:05:54 sorry 18:05:57 let's move on as you said 18:06:00 thanks amrith 18:06:00 lots to do today 18:06:16 #topic hacking rules 18:06:24 18:06:24 Changes being proposed introduce checks for E128, E265, E713, H238, E111, E122, E123, E128, E251, E265, E713, H105, H306, H404. In the past (most recently 2014-07) we discussed some of these (H306, 404) and decided not to take them. 18:06:24 I've looked at many of these hacking rules and they seem to provide little if any benefit to us. I'm dubious about taking them and would like to avoid the (IMHO, needless) churn. 18:06:24 I am definitely not in favor of doing this as multiple changes in one project because of the number of files being changed, in a couple of cases, more than once and the attendant merge conflicts they are bound to bring. 18:06:27 18:07:38 I am a fan of the one with the import order because I am tired of people commenting about it in reviews and rather have it mechanical 18:07:51 On the other hand, once the churn is over PEP8 handles enforcing the rules... 18:08:14 same was my intent also behind 306 because it was raised too many times in reviews 18:08:16 I agree, I had a patch set on that and was going to discuss at the meeting before submitting. but I was scooped. 18:08:47 I'm not sure how much benefit brings us to us to follow all those hacking rules 18:08:52 I think that more rules are enforced by the infrastructure the less likely we end up arguing about style... 18:08:55 the more we can bullet proof the coding style the less trivial comments on reviews 18:09:09 edmondk++ 18:09:09 well, I'm ok with H306 (import order). 18:09:11 that's true 18:09:12 +1, thats what styles are for 18:09:15 but why do we want the rest 18:09:21 yes, there are lots of styles, why stop here 18:09:27 I can find a dozen more hacking rules to enable 18:09:34 and make the same argument; that tox will enforce it 18:09:42 and there are new 'rules' added regularly 18:09:45 so where does this stop? 18:09:55 I say we take H306 and deep-six the rest. 18:09:57 I'm not sure what each one of the rest are — perhaps some of these actually improve readability of the code? 18:09:57 that's my vote 18:10:36 If people are commenting on something it's probably worth enforcing with a rule 18:11:22 but they aren't except for H306 18:11:30 We had much the same discussion in 2014-07 18:11:32 I have to look at each rule 18:11:41 and we decided not to take all of these rules. 18:11:44 Not sure what they all are off hand 18:12:08 E128: continuation line under-indented 18:12:13 I have the list 18:12:15 if you'd like 18:12:16 ;) 18:12:23 Yes, I agree. I think we are being a little hypocritical here — if someone comments on a patch with a style change that improves readability, we say that we shouldn't do that since it's not enforced by pep8. And at the same time we are stringent on letting style checks merge. 18:13:07 amrith: If you can paste the list of rules with a description that would be helpful 18:13:10 SlickNik, with the exception of H306, we aren't 18:13:19 E128, E265, E713, H238, E111, E122, E123, E128, E251, E265, E713, H105, H306, H404 18:13:25 Oh, description 18:13:27 yes, will paste that 18:13:33 I thought E128 was already enforced. maybe I am wrong 18:13:38 Everything is in the commit msg: https://review.openstack.org/#/c/184606/ 18:14:05 - E111 indentation is not a multiple of four - E122 continuation line missing indentation or outdented - E123 closing bracket does not match indentation of opening bracket's line - E128 continuation line under-indented for visual indent - E251 unexpected spaces around keyword / parameter equals - E265 block comment should start with '# ' - E713 test for membership should be 'not in' - H105 Don't use author tags - 18:14:05 H306 imports not in alphabetical order 18:14:07 a lot of times the review comments people have suggested that since a style check is not enforced under pep8 so it should not be a reason of -1 review, so why not just enable it under pep8 18:14:16 https://gist.github.com/anonymous/24979ad5a984d25db653 18:14:27 thx edmondk 18:14:39 maybe it would be nice to do it once and for all 18:14:46 I think either let's either accept them all or ignore them all and move onto the next issue... 18:14:50 so we avoid future confusion 18:15:13 Just to be clear ... after all these changes, the ignore line is still 18:15:14 F821,H237,H238,H301,H305,H307,H402,H404,H405,H407,H501,H904 18:15:20 why not enable those also? 18:15:31 And I have a dozen or so more that I'd like to enable ;) 18:15:48 I like most of these actually 18:16:03 closing bracket does not match indentation of opening bracket's line is a good one 18:16:06 i would give my +1 for enabling them 18:16:10 without it code is actually harder to read 18:16:15 i'd argue that we should take a rule unless we can identify a good reason why we don't need it 18:16:16 amrith: because someone hasn't done the work for that as yet. 18:16:16 If it improves the code, I wouldn't be opposed to enabling them all. 18:16:32 so SlickNik these changes change a lot of files. 18:16:37 could we do them as one commit 18:16:42 rather than four or five? 18:16:45 yeah I dont mind all pep8 rules on if the code is currently fixed to allow them 18:16:47 the merges alone are a pain 18:17:15 I think one commit makes the most sense even though it is probably going to be a monster review 18:17:18 anyway, we've discussed this for 15 minutes. I say we decide one way or another and move on. 18:17:35 maybe we could have a hacking rules week, and do that in separate patches in order 18:17:35 personally, I'm opposed to all of them except H306 (ordering of imports). 18:17:43 so we don't have to deal with merging stuff 18:18:12 I think merging and fixing merge conflicts are a way of life in any big open source project. 18:19:04 Yes, I'm inclined to just take these and move on. 18:19:21 +1 for me for merging the patches that are already out 18:19:22 the style check patches should not be difficult to review if they pass the gates :) 18:19:40 i am also in favor of doing them in one go 18:19:49 So that we don't end up wasting time talking about trivial style issues, and that our style doesn't drift from the rest of the OpenStack codebase. 18:20:07 it will only help our code be more consistent which is critical to a project that is spread out among many different developers 18:20:34 so... merge the ones that are up and create a massive one for all the other hacking rules? 18:20:52 OK, then since Sushil has already been working on those he may want to take it as a little projects and incorporate them all in a single patch set? 18:21:01 I don't personally care if we do all the other hacking rules now 18:21:07 edmondk: ++ 18:21:08 the one's that sushil has done is fine 18:21:08 I would STRONGLY urge that we merge them into one patch set 18:21:15 i take it that someone in the community feels it is worth it to invest in this kind of work? 18:21:17 it will make merging these changes easier 18:21:25 yeah merging into one patch set is fine with me 18:21:26 ie. we are all being paid by someone 18:21:47 dougshelley66: I suspect the fact that these rules have made it into hacking means that this is the case. 18:22:18 well given my limited budget, i don't believe i would pay for this vs doing other work 18:22:39 agreed that's why I am not saying to do all the hacking rules 18:22:45 unless someone wants to go do it 18:22:46 +1 18:22:56 we have more important features obviously 18:23:25 sushilkm: merge your hacking rules patch sets into one and lets move on 18:23:29 dougshelley66: and that's okay — the question is not whether we should drop everything else to go do this — the question is if someone puts up a patch with it done, should we allow it. 18:23:53 yup 18:23:57 SlickNik, ok 18:23:58 hmm its an open source project after all 18:24:01 so h404 would take a lot of time since it has another one which shud be incorporated 405 18:24:09 but yes i have done h306 with rest of them 18:24:42 sushilkm: just combine the patches into one 18:24:44 an open source project does not imply that 'any' contribution shall be accepted. just saying. 18:24:56 that's for sure 18:25:31 so do we want say that all pep8 ignores would be fixed in one go or none would be 18:25:34 well, sorry to have brought it up. I thought this would be a 5 minute -1 like it was the last time around. this is just going to cost a bunch of us some hours to merge. ah well. too bad. 18:25:36 but anybody is allowed to submit a change, and we are part of a bigger project that suggests following the rules we mentioned earlier 18:26:12 sushilkm: whichever rules you have fixed currently merge those in one patch and submit the review 18:26:20 sushilkm: you don't need to do anymore 18:26:26 sushilkm: no not all pep8 ignores in one go — just the ones that we're currently fixing submitted as one patch. 18:26:45 Okay, enough time on this — let's move on. 18:27:00 #topic Setting trove meeting agenda through git 18:27:23 Now that this file is available for edit on gerrit, it may be easier to update the contents (maybe)? 18:27:26 that's all I had to say 18:27:32 if there's nothing to do, let's move on. 18:28:02 It's not that onerous to update the wiki page ... 18:28:40 amrith: I think this is for the meeting schedule 18:29:18 SlickNik, there's some old information there that could be changed; that's all, nothing major. moving along ... 18:29:39 I figured that since it is now in gerrit it may be easier. 18:29:42 no biggie 18:29:54 we can talk about this offline, doesn't have to be here given there is more on the agenda 18:29:57 that is more important 18:30:29 yup — I don't think this actually moves the meetings' agenda into git. Just the meeting schedule is in git and published to ical now. 18:30:36 eg. http://eavesdrop.openstack.org/#Technical%20Committee%20Meeting 18:30:44 SlickNik: Right, for the meeting schedule for all the projects, not the meeting agenda 18:30:57 Let's move on — we can take this offline for further discussion. 18:31:06 #topic Switching blueprint ownership/details 18:31:28 If you read the comments I wrote in the agenda, it should be evident what my issue was 18:32:02 I threw up a spec for Redis backup/restore but couldn't update the corresponding bp 18:32:30 Then someone put up a patchset implementing it ... 18:32:45 hm, that's too bad 18:32:48 Just wanted to know what the proper procedure is or should be 18:33:03 did you get in touch with the contributor peterstac? 18:33:20 vkmc, not yet. This happened this morning 18:33:45 The bp was originally submitted by Denis M. and I tried to point it to the spec, but couldn't edit it 18:34:21 peterstac: as an aside, we should figure out why you're not able to edit the bp and fix that. 18:35:01 peterstac: Also seems reasonable to leave a comment in the code with a -1 saying that the code doesn't implement the spec that's out there for it, and reach out to the person who put up the code to see if they're interested in collaborating on an implementation. 18:35:09 SlickNik: yep, I probably should have mentioned that to you when I discovered it :( 18:35:57 +1 SlickNik 18:35:57 #action SlickNik + peterstac to figure out why some BPs are not editable by contributors 18:36:59 SlickNik, I did put a comment on the commit - I'll send out an email directly to the person too 18:37:06 +1 SlickNik 18:37:22 Sounds good, peterstac. Thanks! 18:37:35 I just wanted to make sure that we avoid this in the future - we've got enough to do that we don't need people duplicating work 18:37:49 agreed 18:38:09 ++ 18:38:22 this is quite a common situation, for bugs at least, first time I see someone starts working on a blueprint without asking 18:39:15 Yes, it's generally a good idea to mention in the bug or bp that you're working on it. 18:39:50 I've seen cases where even that didn't help — but hopefully we won't have too many of those. :) 18:40:04 Let's keep going with the agenda. 18:40:15 #topic Trove production deploy. Security concerns and how are we going to tackle those. 18:40:32 I submitted that one :) 18:40:53 so, during the summit we discussed about what is the best way for deploying Trove in production 18:40:58 and we talked about several options 18:41:16 my question is... do we know if there is a preferred way already? 18:42:09 in the summit we mentioned a couple solutions. First was having everything under a trove tenant, and for this we need to provide an alternate nova_client in remote.py 18:42:17 vkmc: Yes, because of the security concern of deploying trove instances into users' individual tenants — we've always deployed trove into either a trove tenant (or a separate mapped tenant per user). 18:42:51 yeah, I'm aware of that 18:42:52 who is working/going to work on the doc for this? 18:42:56 I've been working on cleaning up some code we have for an alternate remote.py that would do this, and pushing a patchset up for that. 18:42:57 This is a different problem then the rabbitmq issue though 18:43:55 edmondk, yeah... but it kinda includes the rabbitmq issue 18:44:22 johnma / vkmc: I am planning on also pushing up a doc to suggest how you can use the alternate remote.py to create instances in a separate trove tenant. 18:44:46 cool, thanks SlickNik 18:44:47 Any volunteers to help me with this? 18:44:48 SlickNik, that sounds good 18:44:55 I would love to help with that SlickNik 18:45:33 I am still unclear what our solution for rabbitmq issue is 18:45:42 for the long run, though, maybe the nova private instance makes sense? 18:46:04 it doesn't fix the rabbitmq situation, but at least it makes it less trivial to access to instances 18:46:14 SlickNik, sign me up 18:46:16 I had heard that Bruno from Catalyst entered a nova blueprint for this - does anyone have a link 18:46:16 edmondk: The only one that I've seen is to set up a seperate vhost / user for each guest 18:46:21 I have been writing it anyway 18:46:23 for other reasons 18:46:32 I have about 20 pages worth already 18:46:37 ;) 18:46:48 w00t 18:46:49 vkmc / amrith: sounds good. 18:46:59 that's awesome amrith :) 18:47:19 dougshelley66, AFAIK that is not up yet 18:47:19 Yes, for the long term, I think the nova hosted (private) vm approach makes more sense. 18:47:43 We kicked off some conversations regarding that at the summit. 18:47:51 cool 18:47:57 SlickNik there was a blueprint entered - do we know where that is 18:48:06 Bruno was going to draft a use case doc and float that to nova / cinder. 18:48:16 ah ok so he hasn't entered it yet? 18:48:28 But I haven't heard from him yet. 18:48:54 dougshelley66: Yes, nothing yet. 18:49:04 We might have to pick up where he left off. 18:49:14 SlickNik, I'm happy to write it and send it up 18:49:21 I have most of the stuff for that anyway 18:49:30 I can send it to bruno if someone has his email address handy 18:49:52 amrith: let's give him another day or so — if not, let us do that. 18:50:15 I'd like to get on this as soon as we can to give it any chance of actually landing this cycle (which might still be a stretch). 18:50:19 amrith, let us know how we can help 18:50:29 SlickNik, +1 18:51:03 well, bruno has to get to new zealand 18:51:12 that means he will be swimming for some days from sydney 18:51:18 I believe that's the quickest way there 18:51:33 amrith: can confirm. fastest 18:51:36 or wait till the next movie crew for some JRR-T movie decides to go to NZ. 18:52:47 okay, let's move on. 18:53:10 I'm not sure we can wait for the next Tolkien movie :) 18:53:18 I'm sure I can't 18:53:27 #topic Trove multitenancy 18:53:36 if it turns out to be the hobbit, not worth waiting ... moving along. 18:53:42 that's another thing I wanted to ask 18:53:47 probably you discussed about this several times 18:54:08 so we can discuss it later if we don't have enough time now 18:54:31 but, my question is, has this ever been discussed? or is that out of our plans, by design? 18:54:37 i suggest we get started, I'd like to know what the question is. 18:54:50 there you go ^ 18:54:56 or putting it differently, the use-case. 18:55:51 vkmc: This topic has come up a couple of times before. Our stance has been that since we don't get into the data layer — we always provision instances per tenant. Hence we're not getting into a multi-tenant model. 18:56:58 so, if you are in a public cloud and you want to provision datastores for different tenants 18:57:28 you cannot do that? 18:57:45 vkmc, you cannot do what? 18:58:02 access to provisioned datastores from different tenants 18:58:17 sharing a provisioned datastore across tenants? 18:58:28 yeah 18:58:56 That would be a huge security hole unless the database specifically supported it. 18:59:32 So this is a longer discussion that we have time for. 18:59:38 does something prevent it right now? i.e. if one tenant launched a database he or she could allow another tenant to connect to it by suitable networking magic, no? 18:59:57 Let's take it to the trove room. 19:00:00 right 19:00:04 sure, thanks SlickNik 19:00:06 thx 19:00:10 #endmeeting