16:01:24 <dims> #startmeeting oslo
16:01:24 <openstack> Meeting started Mon May  4 16:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:27 <openstack> The meeting name has been set to 'oslo'
16:01:34 <dhellmann> o/
16:01:45 <dims> courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith
16:01:45 <dims> courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith
16:01:47 <bknudson> hi
16:01:50 <kgiusti> o/
16:01:52 <jd__> o/
16:01:52 <zzzeek> o/
16:01:58 <harlowja_at_home> sup dawgs
16:01:58 <dansmith> o/ (kinda)
16:01:59 <redrobot> o/
16:02:01 <sileht> o/
16:02:02 <jd__> dims: I need to leave in 30 min so if you need me push my topics first ;)
16:02:04 <GheRivero> o/
16:02:08 <dims> jd__: ack
16:02:30 <ozamiatin> o/
16:02:38 <flaper87> o/ (kinda)
16:02:55 <dims> let's get started.
16:03:02 <dims> #topic Review action items from previous meeting
16:03:11 <dims> 1. dims send email to -dev list requesting volunteers for liaisons (DONE)
16:03:11 <dims> 2. dims to research oslo mid-cycle possibilities (IN PROGRESS)
16:03:55 <dims> i've sent out a call for liaisons, if you know anyone who may be interested, please ping them
16:04:14 <dims> #topic Red flags for/from liaisons
16:04:16 <bnemec> o/
16:04:36 <dims> any fallout from the release or the uncapping of requirements?
16:04:39 <bknudson> None for keystone that I know of
16:04:43 <dims> hi bnemec
16:05:17 <dims> dhellmann: one question i had was not all python clients seem to have their requirements synced to global requirements for stable/kilo.
16:05:36 * stevemar sneaks in
16:05:42 * dhellmann is on the phone
16:05:57 <dims> dhellmann: ack. we can talk later
16:05:59 <dims> hey stevemar
16:06:07 <dims> switching topics
16:06:08 <dims> #topic Releases for this week
16:06:13 <dims> Anyone need releases?
16:06:28 * dhellmann hangs up
16:06:44 <dims> zzzeek: or any other oslo.db folks - Do we need https://review.openstack.org/#/c/168942/ in stable/kilo? (and put out a release)
16:06:52 <dhellmann> dims: we are going to discuss dealing with library requirements in stable branches at the summit, so we're holding off on making any other changes
16:07:00 <dims> dhellmann: ack. thanks
16:07:02 <zzzeek> hey
16:07:08 <zzzeek> sorry someone knocked on my door
16:07:19 <zzzeek> i dont think this is critical for kilo
16:07:48 <dims> zzzeek: so we should not merge it unless we want to release it. (i think!)
16:07:53 <dims> right dhellmann?
16:08:04 <dhellmann> dims: I had down on my todo list an oslo.middleware release for this morning, and ended up side-tracked with summit planning
16:08:16 <dims> dhellmann: i can take care of that
16:08:37 <dims> #action dims to release oslo.middlware
16:08:46 <dhellmann> dims: cool, thanks -- normally I wouldn't mind doing it, but today got away from me
16:08:53 <dims> zzzeek: ok with holding up that review?
16:08:57 <zzzeek> dims: yes
16:08:59 <dims> thanks
16:09:13 <dims> anyone else have things that got merged in stable/ branch?
16:09:22 <dims> and needs a release, please ping me later
16:09:33 <dims> #topic Ongoing work & Review priorities
16:09:35 <dhellmann> dims: we shouldn't need anything to test with alpha versions of sqla in stable branches because we won't use alpha versions there
16:09:47 <dims> dhellmann: ack
16:10:05 <dims> jd__: floor is yours, you had stuck reviews
16:10:27 <jd__> what, you want me to whine about all my reviews? awesome!
16:10:32 <harlowja_at_home> lol
16:10:39 * harlowja_at_home gets the popcorn ready
16:10:47 <dims> yep. i think you had 2 that had conflicts :)
16:10:55 <jd__> I think the main issues is this one: https://review.openstack.org/#/c/148500/
16:11:12 <jd__> it seems we agree that the patch is OK but how to propagate that in other projects is a problem
16:11:24 <jd__> as said on openstack-dev, I wrote a couple of patches already and getting the merged is… complicated
16:11:31 <bknudson> I don't think keystone is using strtime
16:11:57 <jd__> basically if we deprecated before removing usage, logs are flooded and people complain, and if we try to remove usage before deprecating, nobody cares
16:12:13 <jd__> anyone has a better plan? :)
16:12:17 <bknudson> ./keystone/token/providers/common.py:                                  'issued_at': timeutils.strtime(),
16:12:19 <bknudson> actually, it is.
16:12:21 <dims> jd__: so let's do #1 :) let them complain :)
16:12:31 <harlowja_at_home> https://review.openstack.org/#/c/177848/ i guess is connected/related (if we really decide PendingDeprecationWarning is better than DeprecationWarning)
16:12:35 <dhellmann> what I'm doing with the namespace patches is submitting them, and then I'll submit changes to our libraries with Depends-on set to the patches in the other projects
16:12:46 <jd__> dims: dhellmann thinks that this does not help Oslo reputation (and I understand that)
16:13:03 <dhellmann> right, when we make it look like we're spamming the logs or breaking the gate, it makes projects think twice before using our libraries
16:13:14 <bnemec> Could we mark it deprecated in the docstring first so we have something to point at when we submit patches to other projects?
16:13:22 <jd__> dhellmann: well but nobody will care about your patches :(
16:13:22 <dhellmann> bnemec: I like that
16:13:27 <bnemec> Then once we think we've got it everywhere turn on the warning.
16:13:30 <dhellmann> jd__: some of mine are already merged, actually
16:13:40 <jd__> dhellmann: lucky you :p
16:13:47 <jd__> dhellmann: I guess those are less controversial
16:13:48 <dhellmann> although in my case it has been an ongoing project, so there's more awareness
16:13:49 <dhellmann> yeah
16:13:51 <dims> bnemec: +1
16:13:58 <jd__> bnemec: that might be a good plan
16:14:06 <bknudson> if it's proposed to keystone I'll put it on my short list
16:14:13 <dims> bknudson: thanks!
16:14:16 <dhellmann> we can also ask for liaisons to help with patches, so jd__ doesn't have to write them all himself
16:14:30 <dhellmann> mine are mostly mechanical, so I have a script that produces them so I don't mind doing it myself
16:14:41 <dims> jd__: which project did you have most trouble with? (cinder?) any help from liaison?
16:14:42 <bknudson> my reviews in keystone take a long time to merge since I can't +2 them.
16:15:04 <dims> bknudson: throwing a hint at keystone cores? :)
16:15:11 <jd__> dims: CInder mainly, and nova a bit too
16:15:19 <stevemar> bknudson, you have too many to review :P
16:15:22 <dhellmann> jd__: I also suggest including in the commit messages in the other projects a deadline after which we're going to consider the deprecation in effect. In this case that would mean saying something like "we will add a deprecation warning to the logs after L-2" or whatever deadline you pick
16:15:23 <bknudson> it's a hint to jd__ that it would be better if he submitted it
16:15:33 <jd__> dims: I didn't try reaching liaison, my past experiences discouraged me
16:15:58 <jd__> but I'm clearly not going to write any more patches at this stage
16:16:04 <dims> jd__: y, i'll pester^H^H^H^H^H^Hencourage them jd__
16:16:05 <jd__> so yeah, liaison that's a work for you
16:16:28 <dhellmann> jd__: see https://review.openstack.org/#/c/178281/ for example
16:16:31 <bknudson> is there a bug already?
16:17:51 <jd__> bknudson: about strtime? no
16:17:56 <dhellmann> dims: maybe we should write up a generalized version of this process for future reference
16:18:04 <bknudson> part of the point of strftime is that we can override utcnow and get the same time all over
16:18:10 <dims> dhellmann: spec or wiki?
16:18:16 <jd__> bknudson: that's still covered
16:18:20 <dhellmann> dims: we moved all of our policies to the spec repo, didn't we?
16:18:25 <dims> y
16:19:10 <dims> dhellmann: if you have some notes, i can turn it into a spec, since am sure you are busy with summit work
16:19:10 <jd__> dhellmann: dims: I think it's a good idea. It's a bit sad, but it seems we need to have policy and things that make some kind of authority to push things forward and remove technical debt in the project
16:19:56 <bknudson> python warnings also provides a pending deprecation warning
16:20:20 <dhellmann> dims: I think just the discussion from this meeting, although I could give you more detail on justification for not just throwing deprecation warnings around
16:20:40 <dims> dhellmann: cool, i'll get started and you can throw your notes in comments
16:20:42 <harlowja_at_home> bknudson, https://review.openstack.org/#/c/177848/ ;)
16:20:43 <dhellmann> jd__: the point of writing it down is to say to the next person, "this is what we figured out that works"
16:20:57 <bknudson> harlowja_at_home: nice!
16:21:00 <harlowja_at_home> :)
16:21:01 <dhellmann> dims: sounds good
16:21:03 <dims> #action dims to write up how to deprecate better to avoid adoption issues
16:21:21 <bnemec> Wasn't this also going to be a summit topic?
16:21:28 <dims> also, please touch up reviews (kilo->liberty)
16:21:38 <jd__> harlowja_at_home: once you release that I'll rework my patch to use it :)
16:21:43 <dhellmann> so, short term, if jd__ submits a patch to just document the deprecation I will +2 that so we can point to it as "fact" for anyone objecting to patches anywhere else
16:21:45 <dims> y bnemec, trying to put together so we can talk more at summmit
16:21:47 <harlowja_at_home> jd__,  sure thing boss
16:22:07 <jd__> dhellmann: is doc + PendingDeprecationWarning ok?
16:22:14 <jd__> dhellmann: or does it spam too?
16:22:15 <bknudson> so I just want to be clear on one thing -- you all agree that strtime is going away?
16:22:22 <bknudson> because the review has a -2 on it.
16:22:34 <dhellmann> jd__: I don't know if it generates multiple log messages or not :-/
16:22:47 <dims> bknudson: yes, i believe it was a procedural -2
16:22:47 <jd__> dhellmann: ok! I'll give it a try
16:23:06 * dims takes back floor :)
16:23:16 <jd__> go ahead dims :)
16:23:16 <dhellmann> bknudson, dims : right, I wanted us to work out the process first
16:23:27 <dims> specs, please touch up from kilo -> liberty
16:23:28 <dims> #link https://review.openstack.org/#/q/project:openstack%2Foslo-specs+is:open,n,z
16:24:15 <dims> anyone wants to bring up any spec for a quick discussion?
16:24:44 <dims> k
16:24:47 <dims> #topic liberty planning
16:24:56 <dims> anyone have conflicts that i need to address?
16:25:05 <dims> #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning
16:25:06 <dims> #link https://libertydesignsummit.sched.org/overview/type/design+summit/Oslo
16:25:22 <dims> if someone can't make it to a session and wants me to present their POV, let me know please
16:25:28 <harlowja_at_home> or man those titles are super-awesome, haha
16:25:32 <harlowja_at_home> *oh mn
16:25:34 <harlowja_at_home> *oh man
16:25:37 <dims> harlowja_at_home: ++++
16:25:41 <harlowja_at_home> lol
16:25:53 <dims> i will populate descriptions today
16:26:04 <dims> #topic Open discussion
16:26:26 <dims> so nova has a tool for abandoing reviews - i was trying to see if it will be useful for us - https://review.openstack.org/#/c/179780/
16:26:51 <dims> old stale reviews basically
16:26:57 <dims> 12 weeks with a core reviewer blocking with -2
16:27:01 <harlowja_at_home> so another library that oslo could adopt, tardis (unless people have a better name); bascially the code from https://github.com/openstack/taskflow/blob/master/taskflow/types/futures.py
16:27:03 <dims> 12 weeks without comment and failed Jenkins test
16:27:07 <dhellmann> dims: how many reviews does that apply to?
16:27:08 <harlowja_at_home> just wanted to fyi people on that
16:27:22 <harlowja_at_home> http://sourceforge.net/p/pypi/support-requests/494/ (me trying to get name of that pypi package back from dead? owner)
16:27:25 <dims> dhellmann: this morning yielded about a dozen or so
16:28:10 <harlowja_at_home> oslo.messaging i think wants to use/share that (so hopefully can have that for liberty)
16:28:20 <dims> so far only the following projects
16:28:20 <bknudson> oslo doesn't have friday meetup?
16:28:21 <dims> PROJECTS="(project:^.*openstack/oslo.*)"
16:28:34 <dhellmann> ok. I'm not generally in favor of auto-abandoning reviews. I used to be, but the case has been made by different folks on the mailing list that it's somewhat socially hostile, and so I've changed my mind.
16:28:51 <dhellmann> harlowja_at_home: sounds good! do we need a spec or just a blueprint?
16:28:58 <harlowja_at_home> dhellmann, oh, i should do that
16:29:10 <sileht> dhellmann, just BP should be sufficient
16:29:21 <dims> dhellmann: how do we raise awareness to old reviews? is there a better way?
16:29:22 <dhellmann> bknudson: no, I don't think we asked for one because usually people need to work in their other projects then
16:29:23 <harlowja_at_home> or that to, i'm ok with whatever :-P
16:29:39 <sileht> dhellmann, I have already a PoC for oslo.messaging that replace the executor code with the taskflow lib
16:29:45 <dims> dhellmann: should it just add a message and not abandon?
16:29:48 <dhellmann> dims: we could work on a dashboard query, and maybe get someone to volunteer to pick a few to highlight each week at the meeting?
16:30:14 <harlowja_at_home> i can throw a quick-spec together though if people want, no biggie
16:30:15 <dhellmann> dims: adding a message is good, sure
16:30:16 <bnemec> This is only to abandon things that _cannot_ merge though, right?
16:30:23 <bnemec> Not things that need review.
16:30:28 <dims> harlowja_at_home: +1
16:30:34 <dhellmann> harlowja_at_home: it's sort of nice to have a vote recorded to show the support for taking on the maintenance work
16:30:41 <harlowja_at_home> ok dokie
16:30:45 <dims> bnemec: right, either -2 from core or -1 from jenkins
16:30:48 <dhellmann> but it's also pretty obvious that we'll do it :-)
16:31:01 <harlowja_at_home> #action harlowja_at_home do spec for tardis (or whatever it will eventually be called)
16:31:21 <dhellmann> bnemec: right, and we could set up the dashboard query to ignore those so we just don't see them if that's the issue.
16:31:40 <dims> harlowja_at_home: under oslo namespace?
16:31:53 <harlowja_at_home> eck, doesn't seem needed
16:31:57 <dhellmann> I think this is intended to be standalone
16:32:05 <dims> do we need a spec then dhellmann?
16:32:35 <bnemec> dhellmann: Yeah, I just think we're talking about two completely separate sets of reviews - unmergeable ones that would be auto-abandoned by the tool, and old reviews that just need reviewer love.
16:32:43 <dhellmann> dims: well, on the one hand we're asking the team to sign up for additional maintenance work so it's nice to make that explicit. OTOH, we could just vote in the meeting or something.
16:32:45 <harlowja_at_home> make as standalone as we can, and if can't then oslo namespace (but i forsee future where not needed to do that, hopefully)
16:33:10 <dims> harlowja_at_home: ack
16:33:12 <dhellmann> dims: we don't *need* a spec in this case, since we're just moving code from one place to another
16:33:30 <dims> dhellmann: +1
16:33:45 <harlowja_at_home> dims,  imho its similar to https://review.openstack.org/#/c/141961/ (which is yet another standlone library like thing)
16:33:52 <bnemec> Is there any api work needed though?
16:33:57 <bnemec> This is kind of like a graduation.
16:34:04 <dims> right
16:34:26 <dhellmann> right, the other point of the spec would be to document any additional work that needs to be done
16:34:27 <harlowja_at_home> no api work needed afaik, i write perfect code obviously, lol
16:34:33 <dhellmann> heh
16:34:35 <bnemec> :-)
16:34:36 <dims> haha
16:35:03 <dhellmann> so if we don't think we need a spec, that's fine -- it's a tool for the team to decide how to use :-)
16:35:16 <harlowja_at_home> i write one anyway
16:35:19 <harlowja_at_home> not especially tough :-P
16:35:42 <dims> ok switching topics then
16:35:44 <harlowja_at_home> people can -2 it if they want (and tell me to put it in garbage bin), either way
16:35:44 <dims> #topic Open discussion
16:36:07 <dims> oops, we are already in open discussion :)
16:36:26 <harlowja_at_home> more discussion!
16:36:42 <dhellmann> more open!
16:36:47 <dims> yay!
16:36:50 <harlowja_at_home> ha
16:36:51 <bnemec> +open
16:36:58 <dims> who is excited about Go stuff in swift? :)
16:37:09 <harlowja_at_home> :-/
16:37:13 <dims> do we want to experiment with something?
16:37:24 <bknudson> we'll need to redevelop all of oslo in go
16:37:30 <harlowja_at_home> i'm more on the meh side of it honestly
16:37:31 <bknudson> and a lot of python libraries
16:37:38 <bnemec> Nah, swift doesn't use Oslo anyway. :-)
16:37:58 <harlowja_at_home> swift has always been special, i guess they want to be more special, idk
16:38:19 <dims> haha
16:38:20 <notmyname> wow
16:39:13 <bnemec> dims: opened a can of worms here ;-)
16:39:35 <harlowja_at_home> to each there own though, just brings back memories of zookeeper and java ( http://lists.openstack.org/pipermail/openstack-dev/2013-October/017916.html )
16:40:09 <dims> notmyname fwiw, i am interested in the experiement and learning!
16:40:16 <dims> where can i pay attention?
16:40:55 <notmyname> dims: we've got a feature/hummingbird branch in the swift repo. and code will be in gerrit. and we'll talk in vancouver. of course in #openstack-swift. normal "talk about code" places.
16:41:20 <dims> notmyname: thanks just wanted to be sure
16:42:13 <dims> flaper87: i saw a thread on pecan/falcon etc. any oslo implications there?
16:42:26 <flaper87> dims: none
16:42:31 <dims> #link http://markmail.org/message/zqw4fijc4tmhhwup
16:42:50 <dims> thanks flaper87
16:42:58 <dims> that's all i had in terms of general news
16:43:17 <dims> let's wrap it up then
16:43:17 <flaper87> np :)
16:43:23 <harlowja_at_home> woot
16:43:28 <dims> thanks everyone
16:43:30 <dims> #endmeeting