16:00:07 <dhellmann> #startmeeting oslo
16:00:08 <openstack> Meeting started Fri Sep 19 16:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <openstack> The meeting name has been set to 'oslo'
16:00:17 <dhellmann> who's around for the oslo meeting?
16:00:18 <zzzeek> o/
16:00:22 <dims_> o/
16:00:23 <sileht> o/
16:00:25 <jecarey> o/
16:01:07 <bknudson> hi
16:01:09 <harlowja_at_home> \o
16:01:18 <kgiusti> o/
16:01:24 <beekneemech> o/
16:01:31 <dhellmann> as usual our agenda is in the wiki:
16:01:35 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:01:43 <dhellmann> #topic Review action items from previous meeting
16:01:48 <dhellmann> dhellmann review all libs for unreleased changes that need to go out on monday
16:01:50 <dhellmann> DONE
16:01:53 <dhellmann> we have released all the things
16:01:58 <beekneemech> \o/
16:01:58 <dims_> w00t
16:02:25 <dhellmann> good work, everyone!
16:02:56 <dhellmann> #topic Red flags for/from liaisons
16:03:00 <dhellmann> ok, what'd we break? :-)
16:03:27 <dhellmann> is anyone reporting issues with the final releases?
16:04:20 <dhellmann> I see a few critical bugs:
16:04:21 <dhellmann> #link https://bugs.launchpad.net/oslo/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes
16:04:21 <dhellmann> .used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
16:04:27 <dhellmann> ouch
16:04:40 <dhellmann> http://bit.ly/1o9f8F6
16:04:42 <dhellmann> #link http://bit.ly/1o9f8F6
16:04:42 <bknudson> I haven't seen any bugs to keystone since the oslo libs release
16:05:17 <zzzeek> there is a review for https://bugs.launchpad.net/oslo.db/+bug/1330763, let me find
16:05:18 <uvirtbot> Launchpad bug 1330763 in oslo.db "PostgrestSQLOpportunisticFixture fails with no attribute named _details" [Critical,Triaged]
16:05:22 <dhellmann> the pbr bug blocked us from releasing pbr, so it would be good to have some reviews on that -- maybe we can do a release right after the other projects finish their releases
16:05:39 <zzzeek> this one https://review.openstack.org/#/c/120923/
16:06:02 <dhellmann> ok, I"ll mark that as in progress
16:06:23 <zzzeek> which also, when we ever get to my test rework, is also fixed :)
16:07:18 <dhellmann> bknudson: ok, good to know
16:07:48 <beekneemech> Does anyone have time to fix up that oslo.db change?
16:07:56 <beekneemech> It's still broken if you run locally.
16:08:00 <dims_> dhellmann: pbr review has 2 +2's not sure why it's not +W'ed https://review.openstack.org/#/c/122234/
16:08:18 <dhellmann> dims_: I think because those +2 came before the test jobs finished
16:08:20 <zzzeek> is this fix still considered part of juno ?
16:08:39 <dhellmann> zzzeek: if we need to provide it for the juno versions of the other projects, then it would be
16:09:45 <dhellmann> zzzeek: is that failure happening regularly? why is this old of a bug marked as critical?
16:09:59 <zzzeek> dhellmann: not sure.   i think the nova folks got into it
16:10:04 <dhellmann> ok
16:10:20 <dhellmann> let's see if we can close that out, and I'll talk to ttx about the most appropriate way to release the fix next week
16:10:49 <dhellmann> same for pbr
16:11:05 <dhellmann> #action dhellmann talk to ttx about timing for oslo.db and pbr releases
16:11:22 <dhellmann> #topic Juno Retrospective
16:11:30 <dhellmann> We have some good notes in the etherpad I sent out yesterday
16:11:31 <dhellmann> #link https://etherpad.openstack.org/p/oslo-juno-retro
16:11:49 <harlowja_at_home> beekneemech, https://review.openstack.org/#/c/120923/ fixed ...
16:12:48 <dhellmann> some of these items deserve more discussino than I think we'll have time for here in the meeting
16:12:51 <beekneemech> harlowja_at_home: Thanks
16:13:06 <dims_> dhellmann: there was a vote for rados on mailing list, can you please add him as oslo.vmware specialist?
16:13:13 <dhellmann> dims_: sure
16:13:23 <dhellmann> #action dhellmann add rados to oslo.vmware core list
16:14:14 <dhellmann> if you've been holding onto an idea for a way to improve the way we work, this is the time to bring it up :-)
16:14:30 <harlowja_at_home> make oslo sexy!
16:14:30 <dhellmann> does anyone have questions about any of the items on the list so far?
16:14:40 <dims_> dhellmann: "super +1" concept, we can formalize it?
16:14:49 <dims_> dhellmann: http://markmail.org/message/hhld2vhk2sciwcba
16:14:50 <dhellmann> dims_: super +1?
16:15:04 * beekneemech coined a phrase, apparently :-)
16:15:04 * dhellmann is behind on the ML
16:15:12 <dims_> beekneemech: :)
16:15:18 <beekneemech> I just sent it like 20 minutes before the meeting
16:15:43 <dims_> beekneemech: i liked it a lot :)
16:16:30 <dhellmann> beekneemech: I think I like that, too. We'll have to think about how to implement it in practice, like remembering who gets the ++1 vs. +1
16:16:31 <beekneemech> It seemed to work reasonably well for incubator.
16:16:47 <dims_> dhellmann: right
16:16:48 <dhellmann> maybe just a maintainers file for the drivers
16:16:48 <kgiusti> +1
16:17:03 <dims_> +1 to maintainers file
16:17:05 <beekneemech> +1 to maintainers file
16:17:07 <dhellmann> we could also encourage some of those driver authors to become oslo.messaging cores :-)
16:17:09 <beekneemech> Heh
16:17:29 <beekneemech> dhellmann: That would be nice.
16:17:33 <dims_> basically we build pool of folks we can co-opt!
16:17:44 <dhellmann> dims_: sssh, you're going to give away the secret plan!
16:17:49 <dims_> :)
16:18:49 <dhellmann> ok, beekneemech, would you post those extra details to the list? we can get the other oslo messaging devs to comment that way before going ahead with the plan
16:19:11 <kgiusti> would this effect spinning out the drivers into separate (sub) projects?
16:19:15 <beekneemech> dhellmann: Sure.
16:19:25 <dhellmann> kgiusti: this is an alternative to doing that, yes
16:19:26 <kgiusti> eg - would it eliminate that need?
16:19:29 <kgiusti> ok
16:19:44 <dims_> kgiusti: i hope it would eliminate the need for git sprawl
16:19:51 <beekneemech> +1
16:19:58 <dhellmann> kgiusti: that's still an option, but the project management and integration test load goes up every time we add a repository
16:20:10 <kgiusti> +1, I'm leery of bit rot
16:21:29 <dhellmann> is there anything else on the retrospective list we should talk about now? I'll post to the ML for more discussion, too.
16:22:12 <bknudson> I wanted to point out in the retrospective how much code we got out of keystone
16:22:24 <dhellmann> I saw that, that's excellent!
16:22:30 <dims_> bknudson: great stat
16:22:30 <harlowja_at_home> dhellmann,  i'm always ok with more taskflow reviews ;)
16:22:32 <bknudson> this is great for security.
16:22:51 <beekneemech> Heh, less vendorized Oslo code ftw. ;-)
16:22:56 <dhellmann> harlowja_at_home: yep, we need to build up the review team for that lib beyond just core
16:23:02 <dims_> beekneemech: +1
16:23:03 <bknudson> beekneemech: y, we don't need that complaint
16:23:57 <harlowja_at_home> dhellmann, agreed, glance is starting to suck it in/use it, so it'd be nice to figure out how to involved cinder/glance more in the whole process (get ambassadors from them...)
16:24:21 <dhellmann> harlowja_at_home: that sounds like a good way to build the team up
16:24:38 <harlowja_at_home> ya, even if they are semi-active
16:24:47 <dhellmann> yep
16:25:12 <harlowja_at_home> * for those interested, https://review.openstack.org/#/c/85211/
16:25:24 <dhellmann> there's a lot of active development going on there, so it should be easy to attract people if we look in the right places
16:25:51 <harlowja_at_home> agreed
16:26:20 <dhellmann> let's move on then
16:26:21 <dhellmann> #topic Looking ahead to Kilo
16:26:48 <dims_> dhellmann: is there consensus on yanking py26 support?
16:27:10 <dhellmann> dims_: I think we're waiting on SuSE. I expect infra will keep us informed about that.
16:27:30 <clarkb> I think in atlanta we basically said no py26 for kilo
16:27:42 <clarkb> it was twittered so must be official now
16:27:49 <beekneemech> :-)
16:27:54 <dhellmann> clarkb: that's what I remember, but I wasn't sure who would be responsible for actually implementing that across all of the projects.
16:27:55 <dims_> clarkb: lol
16:28:07 <clarkb> one thing to keep in mind though is that the clients must still py26 for old releases
16:28:23 <clarkb> so clients and possibly oslo may py26 for another year
16:28:26 <dhellmann> so that means at least some of the oslo libs will have to be tested for 2.6
16:28:31 <clarkb> yup
16:28:44 <dhellmann> oslo.utils, oslo.serialization (?), maybe some others -- we will have to do that analysis
16:28:52 <dhellmann> stevedore and cliff
16:29:07 <beekneemech> Might be safest just to leave them all.  They're all being tested against 2.6 now anyway.
16:29:26 <dhellmann> yeah, we know some of the libs are only used in the servers, but it's just as easy to keep them all for now
16:30:00 <dhellmann> as some of you know, markmc is going to be focusing on some internal work at red hat for kilo, so he has stepped down as the lead on oslo.messaging
16:30:12 <dhellmann> I've asked sileht to take over those responsibilities, and he agreed
16:30:25 <dhellmann> #info silent is our new lead for oslo.messaging
16:30:30 <beekneemech> sileht++
16:30:34 <dims_> dhellmann: +1 to sileht
16:31:17 <dims_> clarkb: while we have you, i saw notes on py34 is that as a replacement for py33?
16:31:43 <dhellmann> dims_: oh, yes, good question -- I think I saw mention that we had a project failing the tests under 3.4?
16:31:52 <dims_> oslo.utils dhellmann
16:32:04 <dhellmann> hrm, that's surprising
16:32:05 <harlowja_at_home> i was gonna try to fix that today unless someone else is working on it
16:32:06 <dhellmann> do we have a bug filed?
16:32:09 <clarkb> I think we are leaning that way. aside from f20 py33 does not have a large install base but 34 is going to be in lots of stuff?
16:32:18 <harlowja_at_home> dhellmann, i can open one with the details of whats broken
16:32:22 <harlowja_at_home> *once i get into work
16:32:27 <dhellmann> clarkb: picking one version of py3x makes sense to me
16:32:37 <dhellmann> harlowja_at_home: ok, thanks
16:32:50 <dhellmann> #action harlowja_at_home open a bug to track fix for oslo.utils py34 test job
16:32:51 <clarkb> anyways we would like to shift the bulk of py3k testing to 34 because its easy for us to test and easy for users to consume
16:32:59 <dhellmann> ++
16:33:04 <harlowja_at_home> np, the part that made me sad was the we published oslo.utils on pypi with stated py33 support but its still not voting :-/
16:33:22 <dhellmann> harlowja_at_home: nice seque
16:33:26 <dhellmann> segue
16:33:28 <dims_> harlowja_at_home: y the comments from clarkb and fungi were on that review i had for making them vote
16:33:32 <dhellmann> #info we need to wrap up some details for our new libs: https://docs.google.com/spreadsheets/d/1MvXsg0XxPonJ8yAFSraIwHM940eAfoXhfBVRa6hN7MY/edit#gid=0
16:34:10 <dhellmann> we have a few doc items to connect, a few jobs to make sure we have set to voting, etc. We should prioritize that work now, so we're completely done with what we started in Juno before we start the Kilo work.
16:34:22 <harlowja_at_home> dims_, yes i know comments on review for infra, still made me a little sad :-P
16:34:31 <dhellmann> please look over the list of incomplete items for your libs on that spreadsheet
16:34:41 <dims_> dhellmann: related question, what is the next set of code to library-ize?
16:34:51 <dhellmann> dims_: we need to work that out
16:35:06 <bknudson> is oslo.concurrency released for juno?
16:35:07 <dhellmann> I plan to do some work on that next week, and start a discussion on the ML
16:35:17 <dims_> sounds great
16:35:31 <dhellmann> dims_: if you have ideas, let me know :-)
16:35:51 <dims_> dhellmann: ack :)
16:35:51 <dhellmann> bknudson: we had a pre-1.0 release, but it's not marked as final on https://etherpad.openstack.org/p/juno-oslo-feature-freeze
16:36:08 <beekneemech> Okay, and we can unblock all of the stuff like https://review.openstack.org/#/c/118218/ right?
16:36:27 <dhellmann> boy, you guys are 1 step ahead of me today
16:36:28 <dhellmann> #info it is time to start removing deprecated code from the incubator
16:36:36 <beekneemech> Heh
16:36:37 <dhellmann> unleash your git rms
16:36:53 <harlowja_at_home> lol
16:36:57 <beekneemech> Ooh, it's rpc delete time, right?
16:37:00 <dhellmann> we'll need to coordinate, so that we update the modules that stay behind to use libraries appropriately
16:37:05 <beekneemech> So we can go back to having sane tox envs.
16:37:06 <dhellmann> oh, yes, please, please delete that first
16:37:16 <dims_> hehehe
16:37:22 <dhellmann> jd__: has a patch up for that, and we need to ressurect it and make sure it's still correct
16:37:51 <dhellmann> #info while we are deleting code, fixes to incubated code needed by the other projects will need to be applied to the new stable/juno branch
16:38:00 <dims_> dhellmann: don't see oslo.concurrency here - https://review.openstack.org/#/c/121621/
16:38:07 <dhellmann> we'll have to decide on a case-by-case basis where to apply a patch first
16:38:25 <dhellmann> dims_: ah, I can abandon that one, we landed 2 other patches instead
16:39:00 <dims_> nice
16:39:00 <dhellmann> abandoned
16:40:16 <dhellmann> dims_: you have a patch somewhere to update the incubator to use oslo.utils, right?
16:40:28 <dims_> dhellmann: y will freshen it up
16:40:33 <dhellmann> ok
16:41:07 <dhellmann> one of the things I'd like us to try for kilo is using launchpad for scheduling work with bugs as well as blueprints
16:41:18 <dhellmann> so let's file some bugs for the delete work, and put them in the appropriate next-kilo milestone
16:41:30 <dhellmann> maybe one bug per library?
16:41:38 <dhellmann> associated with the incubator project
16:42:03 <beekneemech> Seems reasonable
16:42:43 <dhellmann> that will also let us start using the launchpad milestone as a way to figure out what reviews to prioritize
16:43:17 <dhellmann> we dont need bugs for every little change, but for things we agree are team priorities it helps to have a list somewhere
16:43:28 <dhellmann> and etherpads were really not scaling well
16:44:07 <beekneemech> So. many. etherpads.
16:44:15 <harlowja_at_home> lol
16:44:24 <dhellmann> ttx created a nice release script for us that closes the milestones, marks the bugs as "fix released", and then tags the repository
16:44:36 <dhellmann> library releases will be much less manual during kilo :-)
16:45:13 <dhellmann> one last item
16:45:14 <dhellmann> #topic review priorities for this week
16:45:20 <dhellmann> #info incubator cleanup
16:45:26 <dhellmann> #info any critical bugs
16:45:30 <dhellmann> #link http://bit.ly/1o9f8F6
16:45:47 <dhellmann> do we have any changes in play without bugs on that list? ^^
16:46:17 <dims_> not that i know of
16:46:28 <harlowja_at_home> nothing critical from my side
16:46:46 <dhellmann> beekneemech, you asked about lower priority changes earlier. do you think it makes sense to do the cleanup work first, then deal with merge conflicts to those changes.
16:46:49 <dhellmann> ?
16:47:18 <beekneemech> Hmm
16:47:37 <beekneemech> Probably.  There's no sense reviewing changes to code that will be getting deleted.
16:47:38 <dhellmann> or should we merge the little stuff to make it easier to backport them?
16:48:00 <dhellmann> yeah, let's see what we actually have -- some of it we might just ask to have merged in the stable branch and not in master at all
16:48:05 <beekneemech> Well, backports to code getting deleted are going to skip master anyway, right?
16:48:11 <dhellmann> right
16:48:26 <dhellmann> I was thinking of a case that was mixed
16:48:38 <dhellmann> there was something recently, let me find it
16:49:00 <beekneemech> Yeah, but we'll end up with a messy backport for those anyway since some of the files will have disappeared either way.
16:49:13 <dhellmann> true
16:49:27 <dhellmann> oh, the mock thing: https://review.openstack.org/87375
16:49:38 <dhellmann> that one we probably don't care so much about backporting
16:50:17 <beekneemech> Yeah, I wouldn't think so.
16:50:36 <dhellmann> ok, do we want to sign up to work on the deletion stuff so we don't step on each other's toes?
16:50:59 <beekneemech> Seems like a good idea.
16:51:04 <beekneemech> I'm out Mon-Wed next week though.
16:51:21 <dhellmann> #link https://etherpad.openstack.org/p/oslo-kilo-deleting-graduated-libraries
16:51:59 <dims_> we need one etherpad where can we can write down the urls to the rest of them :)
16:52:41 <dhellmann> dims_: haha
16:52:49 <beekneemech> One etherpad to rule them all!
16:53:08 <dhellmann> you know, I just said we'd use bugs for this
16:53:15 * dhellmann needs to stop making etherpads
16:53:27 <beekneemech> Heh
16:53:35 <dhellmann> sign up on the etherpad, and then create a bug and assign it to yourself :-)
16:53:41 <dims_> lol
16:54:52 <dhellmann> that's all I had for today
16:54:56 <dhellmann> #topic open discussion
16:55:09 <beekneemech> dhellmann: Oh, so stuff like https://review.openstack.org/#/c/118218/2/MAINTAINERS will need to go to stable/juno instead of master now.
16:55:20 <beekneemech> Because those modules will get deleted entirely in master.
16:55:28 <zzzeek> so i really want to fix up the way libs use EngineFacade
16:55:45 <zzzeek> because i see like in nova, get_engine() / get_sessino() called all over the place, repeatedly, overlapping, etc.
16:55:49 <dhellmann> beekneemech: good point. Do you think we still need that at all? or is it clear from the fact that we've deleted the code that it is obsolete?
16:56:35 <gordc> zzzeek: you have doc on proper usage? i'd be happy to apply it to ceilometer
16:56:46 <zzzeek> gordc: i have to blueprint some new API
16:56:56 <zzzeek> so i want to make a BP taht pushes for a decorator
16:56:57 <dhellmann> beekneemech: the "obsolete" status was meant to be used for code we were keeping around after graduation, which we won't be doing any more
16:57:12 <gordc> zzzeek: cool cool. that sounds like a good idea.
16:57:17 <zzzeek> there would no longer be any get_session() or get_engine() calls, it confuses everyone.
16:57:22 <beekneemech> dhellmann: Yeah, that makes sense, and it would cut down on the number of boilerplate changes we have to make.
16:57:27 <zzzeek> the decoator would maintain just one transaction no matter how much it is nested
16:57:29 <dhellmann> beekneemech: right
16:57:45 <zzzeek> and could also do the “retry on failed transaction” thing, perhaps with some declarative markers whether or not to enable it for a series of methods
16:57:48 <dhellmann> #action dhellmann update graduation instructions to say delete code instead of marking it obsolete
16:57:51 <bknudson> zzzeek: how? thread-local variable?
16:58:10 <zzzeek> bknudson: the decorator would maintain the state as it calls the wrapped function
16:58:27 <dhellmann> zzzeek: that spec sounds like interesting reading :-)
16:58:52 <zzzeek> dhellmann: its a pretty simple idea, but it means, if you want the DB you would use this decorator, and it feeds an extra argument into your funciton
16:59:01 <zzzeek> ive looked at neutron, they already have a system like this
16:59:15 <zzzeek> well they have a “context”.
16:59:24 <dhellmann> zzzeek: nice, maybe we can bring theirs into oslo
16:59:26 <zzzeek> so they probably woudlnt use this part of it.
16:59:29 <zzzeek> maybe.
16:59:48 <bknudson> that might make some keystone stuff easier, since we have cross-backend calls
16:59:55 <zzzeek> but i still see reviews daily, that confuse get_engine(), get_session(), begin(), and i think it should all be removed from code that uses oslo.db
17:00:00 <bknudson> the called backend might be SQL or it might be LDAP
17:00:08 <dhellmann> we're almost out of time, so I want to say THANK YOU ALL once again for a highly productive cycle
17:00:28 <zzzeek> woop
17:00:40 <dims_> +1000 to all of us :)
17:00:51 <dhellmann> ++
17:00:58 <dhellmann> ok, time's up
17:01:01 <dhellmann> #endmeeting