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