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