18:00:09 <amrith> #startmeeting trove 18:00:15 <mvandijk> o/ 18:00:16 <openstack> Meeting started Wed Sep 21 18:00:09 2016 UTC and is due to finish in 60 minutes. The chair is amrith. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:20 <openstack> The meeting name has been set to 'trove' 18:00:22 <peterstac> \o 18:00:25 <songjian> o/ 18:00:29 <amrith> hiya peter 18:00:35 <schang> o/ 18:00:35 <amrith> hi songjian 18:00:38 <amrith> hi simon 18:00:39 <peterstac> Hi amrith 18:00:43 <amrith> #agenda https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:00:57 <amrith> not a lot on there today, should be quick (I hope) 18:01:19 <pmalik> 😖/ 18:01:41 <songjian> hi,amrith 18:01:49 <amrith> Why is I can never see the things that pmalik types; are they some special funny characters? 18:02:00 <amrith> like, what's the character before "/" 18:02:05 <amrith> hi songjian 18:02:25 <pmalik> amrith Do you have Linux? 18:02:26 <amrith> peter, anyone else you expect from the northern front? 18:02:42 <mvandijk> aliadil 18:02:43 <amrith> pmalik, no, I'm all windoze all the time 18:02:46 <amrith> sometimes DOS 18:02:52 <vgnbkr> o/ 18:02:58 <amrith> also commodore 64; did you hear there is a new c64 emulator 18:03:01 <aliadil> o/ 18:03:05 <amrith> ok, let's get started 18:03:08 <peterstac> amrith, I think we're all here 18:03:11 <amrith> johnma isn't here today it appears 18:03:13 <pmalik> Ah, that's it. Only Linux ppl can see it: http://www.alt-codes.net/smiley_alt_codes.php 18:03:27 <dloi> o/ 18:03:28 <amrith> thx pmalik I feel left out 18:03:31 <johnma> o/ 18:03:42 <amrith> #topic Trove pulse update 18:03:44 <amrith> hi johnma 18:03:53 <amrith> #link https://docs.google.com/spreadsheets/d/1vJxNaoR3VVNS1Cpiz7U--1zyJRZ6ybMxzJoayrjdduo/edit?usp=sharing 18:03:59 <amrith> #link https://gist.github.com/anonymous/adfddaeadd1e715cbc9a4aa64ef75a3a 18:04:00 <johnma> hi amrith 18:04:25 <amrith> the number of reviews fell off sharply (after we cut rc1) 18:04:34 <amrith> hopefully we can keep the numbers up near 100 18:04:38 <amrith> and work through the backlog 18:05:02 <amrith> not a whole lot else to add to that 18:05:37 <amrith> anyone have anything to add ... 18:06:30 <amrith> #topic Newton release schedule 18:06:37 <amrith> so this week we have to release rc2 18:06:45 <amrith> I see only a couple of more things that must merge 18:06:50 <amrith> https://review.openstack.org/#/c/374202/ 18:07:01 <amrith> anything else peterstac ? 18:07:16 <peterstac> That's the only one I'm aware of 18:07:36 <peterstac> I did push up a change to turn off the eject-valid-master in the api tests 18:07:40 <johnma> I will approve that one. 18:07:48 <peterstac> not sure if that's worth pushing back too ... 18:08:06 <peterstac> (since it doesn't hit that often) 18:08:16 <peterstac> thx johnma 18:08:50 <peterstac> here's the link 18:08:52 <peterstac> #link https://review.openstack.org/#/c/374249/ 18:09:32 <amrith> peterstac, sounds good 18:09:36 <amrith> let's get it into master 18:09:40 <amrith> and then backport it 18:09:48 <peterstac> ok 18:09:59 <amrith> I've +1'ed it. thx 18:10:07 <amrith> with that we should be ok with newton 18:10:12 <amrith> the translations appear to have landed 18:10:21 <amrith> I don't see any translation changes in rc2 18:10:35 <amrith> so we should be in good shape; no necessity to do an rc3 18:10:47 <peterstac> (here's the cherry-pick to stable/newton: https://review.openstack.org/#/c/374320 ) 18:10:55 <amrith> if anyone has anything else they feel should make it urgently into rc2, speak now ... 18:11:10 <amrith> yes, that won't work for a stable branch 18:11:14 <amrith> you have to cp -x 18:11:22 <amrith> so wait for master to merge 18:11:25 <amrith> sorry 18:11:44 <amrith> newton is under stable/release team control now 18:12:09 <amrith> peterstac, ok? 18:12:35 <peterstac> not sure what 'cp -x' means in the context of git/gerrit ... 18:12:49 <trevormc> cherry pick? 18:13:03 <amrith> see http://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes 18:13:14 <amrith> peterstack, cherry-pick -x 18:13:52 <peterstac> ah, I just use the cherry-pick button in gerrit :) 18:14:12 <trevormc> same 18:14:20 <amrith> sorry mate ... 18:14:22 <peterstac> yeah, seems to do that by default 18:15:16 <peterstac> ah, but you have to wait until it merges first, got it, thx! 18:15:23 <amrith> yup 18:15:31 <amrith> ok, anyone have anything else for rc2 ... 18:15:46 <songjian> https://review.openstack.org/#/c/372218/ if Peter commit can not backport to stable/newton,I have an new idea to avoid pylint error...maybe can try it with smallest change... 18:16:33 <amrith> songjian, is this a real error? 18:16:36 <amrith> I'm not sure 18:16:58 <peterstac> no, it's an issue because postgresql is split into many files 18:17:01 <amrith> I think _find_user may not exist in postgresql; pmalik would you confirm 18:17:21 <peterstac> that's being fixed in 18:17:24 <peterstac> #link https://review.openstack.org/#/c/346082/ 18:17:54 <pmalik> This whole thing with _find_user is just an artifact of using mixins. 18:18:01 <peterstac> (pylint flags it because one mixin class is calling a method in another mixin clasS) 18:18:01 <amrith> that's what I thought 18:18:09 <amrith> and I think this is a false positive from pylint 18:18:10 <songjian> a code style error,it is not error,because we never create PgAccess object to perform... 18:18:16 <pmalik> The method exist in the manager which iports all of them. 18:18:34 <amrith> would someone confirm that this is a false positive ... 18:18:52 <amrith> or not 18:19:06 <pmalik> Yes, this is a false-positive from pylint. 18:19:33 <amrith> and the issue is that we have two mixins and one mixin has a method calling a method in the other mixin 18:19:35 <peterstac> I pretty sure it's a false positive, but someone else can always confirm it 18:19:46 <peterstac> amrith, yes 18:19:47 <amrith> but at runtime the only class where all this executes is derived from both classes 18:19:52 <amrith> so all is well at runtime 18:19:52 <peterstac> right 18:19:54 <amrith> is that right 18:19:59 <peterstac> yes, correct 18:20:04 <amrith> ok, so I don't thnk we need the fix that songjian proposed 18:20:06 <amrith> is that true? 18:20:30 <peterstac> yes, and with the change listed above to consolidate all the postgresql files, this will go away 18:20:32 <pmalik> It would only be a problem if somebody tried to use that one mixin in isolation, but that's not the case in the current codebase. The 'issue' goes away once we merge all mixins into a single module. 18:20:43 <peterstac> I think we're close the getting that one cleaned up properly 18:21:00 <amrith> pmalik, peterstac, I think the three of us are on the same page. songjian do you agree? 18:21:19 <songjian> ok,thx all 18:21:46 <peterstac> pmalik, you should run 'tox -epylint rebuild' on your change and make sure that it knocks out those exceptions 18:22:00 <amrith> peterstac ++ 18:22:00 <peterstac> (and push up the resulting .config file as well :) ) 18:22:28 <amrith> yes, commits that only reduce exceptions in the .config file are extra welcome 18:23:13 <pmalik> ok 18:23:31 <amrith> if there's nothing more, let's move on 18:23:36 <amrith> #topic Open Discussion 18:23:43 <amrith> I added three 18:23:54 <amrith> #link https://review.openstack.org/#/c/372448/ 18:24:10 <amrith> this was something I wanted to bring to everyones attention 18:24:25 <amrith> at this point pylint is gating in both master and newton 18:24:49 <amrith> thx to peterstac for improving the tool and making the excludes file (hopefully) well ordered 18:24:54 <amrith> consistently ordered 18:25:02 <amrith> that should make it easier for us to manage moving forward 18:25:19 <amrith> if your job fails pylint, it won't merge. 18:25:54 <amrith> that's all I wanted to say, if anyone has questions about pylint, please feel free to ping me, or mariam or peter ... we've all used it a bit and should be able to help if you have problems. 18:26:22 <amrith> #link https://review.openstack.org/#/c/373153/ 18:26:44 <amrith> I wanted to bring everyones attention to this blueprint and I'd like you to review it soon so we can land it early (very soon) in newton. 18:26:49 <amrith> like, the next couple of weeks. 18:26:53 <amrith> if possible 18:27:09 <johnma> sure 18:27:18 <amrith> if you have questions or comments please either put them in the review or catch me on IRC 18:27:36 <amrith> or ... phone, email, come to my house, whatever works for you 18:27:51 <amrith> and the last one 18:27:53 <amrith> #link https://review.openstack.org/#/c/373163/ 18:27:59 <amrith> which i want to ask about here 18:28:08 <amrith> I'll wait till people read it over 18:28:33 * amrith waits ... what do you think about this change? 18:29:03 * trevormc had problems with redstack and am happy there is a change coming :) 18:29:14 * peterstac is still reading ... 18:30:08 <peterstac> do we want to stipulate what cases don't need a bug? 18:30:24 <peterstac> i.e. trivial fixes, etc.? 18:30:37 <amrith> peterstac, I wanted to. but I found it hard to come up with something. what, for example, is trivial? 18:30:40 <peterstac> (I know, who defines what is trivial ...) 18:30:48 <mvandijk> can we get the models improvement merged? 18:30:51 <mvandijk> #link https://review.openstack.org/#/c/236082/ 18:30:58 <amrith> someone thinks https://review.openstack.org/#/c/364631/ is trivial 18:31:00 <amrith> is it trivial? 18:31:12 <amrith> mvandijk, one conversation at a time if we could please 18:31:35 <amrith> peterstac, I don't understand the bug. maybe it is non-trivial 18:32:07 <amrith> tomorrow someone else comes along and says assertTrue() is better 18:32:16 <amrith> what do we do, switch them all back? 18:32:41 <amrith> tomorrow someone adds another assertTrue(p in q), what do we do? start a cottage industry of people doing these stylistic fixes? 18:32:48 <amrith> I'm not sure what the right answer is 18:33:29 <peterstac> typically we've been averse to fixes like that that aren't enforced by pep8/flake8 18:33:42 <amrith> hence also my ML post this morning http://openstack.markmail.org/thread/hvgryw4kdxjugvuu 18:33:44 <peterstac> since as you said they almost immediately regress 18:34:13 <pmalik> I'd suggest if anybody is interested they can propose an official hacking rule to openstack and if that gets accepted we can enable it and make a project to fix our codebase, but otherwise it is questionable... 18:34:43 <amrith> pmalik, peterstac ++ 18:34:45 <pmalik> Yeah, it would be very difficult to keep them from getting back without a pep8 check... 18:35:13 <amrith> but, back to the original question, do we need a bug? 18:35:16 <amrith> in launchpad 18:36:58 <peterstac> well, we could leave it like you've written it and if anyone thinks that a bug is warranted and not supplied they can request one 18:37:28 <amrith> peterstac, playing devils advocate, would that request come with a -1? 18:37:47 <amrith> this is the slippery slope 18:37:57 <amrith> i'm leaning towards not having that be -1'able 18:38:02 <peterstac> I think that would fall under the 'original request is a +0, but if others agree would get elevated to -1' list 18:38:09 <amrith> after all, I'm wondering in the world of reno, what the value is of a lp bug. 18:38:14 <vgnbkr> Did lp bugs serve any purpose other than to keep track of which changes needed release notes? 18:38:24 <amrith> exactly what vgnbkr said 18:38:28 <peterstac> well, it's also useful for triaging 18:38:35 <amrith> but do we triage? 18:38:44 <amrith> bugs come in, changes appear (magically) 18:38:57 <amrith> I think it is useful for non-developers to enter bugs 18:39:20 <amrith> but I see no benefit for developers to enter bugs (other than that in my own case, I use it as a way to keep track of things I want to have fixed) 18:39:29 <amrith> there are certainly those who may not see that value 18:39:53 <amrith> all i'm saying is that I'm fine with fixes with no bug # 18:41:00 <vgnbkr> It would still be useful where a developer wished to log a bug that they don't immediately plan to fix themselves. 18:41:15 <amrith> agreed 18:41:26 <amrith> but that's not a change review conversation, is it? 18:42:09 <trevormc> How about this, if a developer wants to make a change. First they report a bug, then it must be confirmed before they make a change? 18:43:04 <trevormc> i could see how that could slow things down. Not sure if it adds value or not, just an idea. 18:43:25 <amrith> that's a good idea, what do others think of the idea. it certainly isn't the way the rest of openstack works 18:44:33 <johnma> I think that slows down things even more for a developer 18:44:42 <vgnbkr> Don't we already have enough of a momentum problem? 18:44:58 <amrith> vgnbkr, when you put it that way, it sounds like a bad idea :) 18:45:08 <johnma> I am sure there are atleast some folks who may feel frustrated with the pace at which changes are getting merged 18:45:28 <amrith> and it would be another speed bump for changes 18:45:35 <amrith> I see other projects doing fine with out bug #'s 18:45:56 <trevormc> creating bugs just seems like busy work to me. 18:46:15 <amrith> if no one objects to this proposal, let's get it reviewed and merged so we can start living by it ... 18:46:36 <amrith> and with that, I'll pass the baton over to mvandijk who had something he wanted us to talk about. 18:46:39 <amrith> mvandijk ... 18:46:53 <amrith> #action [all] review https://review.openstack.org/#/c/373163/ 18:46:54 <mvandijk> Can we get reviews on https://review.openstack.org/#/c/236082/ ? 18:47:19 <mvandijk> i guess i should explain 18:47:29 <mvandijk> the datastore models are all in one file 18:47:38 <mvandijk> these models being users and schemas 18:47:49 <amrith> it seems to fail all the non voting experimental jobs (almost all). 18:48:14 <mvandijk> we use them for validation of the objects coming in 18:48:41 <mvandijk> so the problem is that client calls coming in all get validated against mysql models 18:48:46 <mvandijk> which isn't right 18:49:04 <mvandijk> and we want to move away from that into validating requests based on the datastore of the target instance 18:49:09 <mvandijk> this is step #1 toward that 18:49:37 <peterstac> mvandijk, I'll take a look at it this week 18:49:37 <mvandijk> once this goes in we can load the models used to check client requests based on the datastore type 18:49:43 <mvandijk> please do 18:49:46 <mvandijk> it has been up 11 months 18:49:59 <mvandijk> thanks 18:50:47 <amrith> mvandijk, I will review as well 18:51:07 <johnma> I will also look at this mvandijk. 18:51:17 <amrith> will this change improve the experimental jobs failure rate? 18:52:32 <mvandijk> probably not on its own no 18:52:54 <amrith> ok, will review this week. looks like a medium sized change 18:53:10 <pmalik> Not on its own. Many experimental jobs fail because of constrained gate resources... 18:53:16 <amrith> will aim to get it reviewed and ifpossible merged 18:53:21 <amrith> ok 18:53:25 <amrith> anything else ... 18:56:48 <peterstac> nothing here 18:57:15 <amrith> johnma, vgnbkr, trevormc, mvandijk, pmalik (anyone else I missed) 18:58:04 <songjian> nothing here... 18:58:12 <amrith> thx songjian 18:58:20 <amrith> sounds like we're almost out of time anyway 18:58:27 <amrith> thanks all 18:58:28 <amrith> #endmeeting