16:00:57 <dhellmann> #startmeeting oslo
16:00:58 <openstack> Meeting started Fri Sep 26 16:00:57 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:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:02 <openstack> The meeting name has been set to 'oslo'
16:01:11 <dhellmann> who's around for the oslo meeting?
16:01:22 <flaper87> o/
16:01:23 <harlowja_at_home> \o
16:01:24 <jecarey> o/
16:01:28 <beekneemech> o/
16:01:45 <viktors> o/
16:01:48 <dhellmann> our agenda, as usual
16:01:49 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:02:11 <dhellmann> dimsum_, jd__, sileht: ping
16:02:18 <jd__> o/
16:02:25 <dhellmann> #topic Review action items from previous meeting
16:02:28 <dimsum_> o/
16:02:38 <dhellmann> #action dhellmann talk to ttx about timing for oslo.db and pbr releases
16:02:44 <dhellmann> I need to carry that over.
16:02:54 <dhellmann> #info dhellmann add rados to oslo.vmware core list - DONE
16:03:03 <dhellmann> welcome, again, rados
16:03:13 <dhellmann> #info harlowja_at_home open a bug to track fix for oslo.utils py34 test job
16:03:22 <dhellmann> harlowja_at_home, can you report on that?
16:03:30 <harlowja_at_home> oh, ya, thats done, fixed up
16:03:49 <harlowja_at_home> https://review.openstack.org/#/c/122823/
16:03:54 <harlowja_at_home> ^ weird
16:04:16 <dhellmann> #link https://bugs.launchpad.net/oslo.utils/+bug/1371724
16:04:17 <uvirtbot> Launchpad bug 1371724 in oslo.utils "test_excutils py34 incompatabilities" [Medium,Confirmed]
16:04:50 <jd__> there's also review on pbr to do I think :/
16:04:54 <dhellmann> I'd love more background for that
16:05:24 <zzzeek> \o
16:05:30 <dhellmann> jd__: for python 3?
16:05:38 <jd__> dhellmann: no, in general
16:05:54 <jd__> I know I've proposed a few patches that are waiting, and there's more
16:05:58 <dhellmann> jd__: yeah, we need to find a lead maintainer for pbr
16:06:20 <jd__> we need at least 2/3 reviewers yeah :)
16:06:21 <dhellmann> I've been hesitating to approve anything there until the semver issue is fixed and we can make a release
16:06:30 <dhellmann> #info dhellmann update graduation instructions to say delete code instead of marking it obsolete - DONE
16:06:39 <dhellmann> I think that's it for actions from last week, did I miss anything?
16:07:28 <dhellmann> #topic Red flags for/from liaisons
16:07:42 <dhellmann> zzzeek reported an issue with oslo.db
16:07:46 <zzzeek> yep
16:07:52 <zzzeek> fixy
16:08:03 <dhellmann> #link https://bugs.launchpad.net/oslo.db/+bug/1374497
16:08:06 <uvirtbot> Launchpad bug 1374497 in oslo.db "change in oslo.db "ping" handling is causing issues in projects that are not using transactions" [Undecided,New]
16:08:29 <zzzeek> im moving the “begin” event to the “engine_connect” event, basically
16:08:45 <dhellmann> we'll need to get set up to do a patch release, since I think we've committed some other changes to oslo.db since the release
16:09:01 * beekneemech is guilty
16:09:19 <dhellmann> zzzeek: when you're ready, let me know and I'll get ttx to set up the branch for us (or give me permissions to do it)
16:09:27 <zzzeek> yup
16:09:50 <dhellmann> beekneemech: it's ok, we expected to need to do this at some point
16:10:05 <beekneemech> Phew :-)
16:10:57 <dhellmann> does anyone else have anything to raise as a flag?
16:11:10 <dimsum_> nope
16:11:33 <dhellmann> bknudson is quiet today :-)
16:11:46 <dhellmann> #topic finishing juno
16:11:56 <dhellmann> We're making good progress cleaning out old code from the incubator.
16:11:56 <dhellmann> We have some work on oslo.log and oslo.concurrency to finish graduating them.
16:12:01 <dhellmann> Is there anything else we left incomplete in juno that should go on that priority list?
16:12:18 <dhellmann> I did open bugs for some of the doc-related tasks
16:12:24 * beekneemech has been hacking at oslo.concurrency this morning.
16:13:34 <dhellmann> I did some work on oslo.log yesterday. I have a list of API changes I want to propose, and I haven't decided if they are worthy of a spec or not.
16:14:15 <harlowja_at_home> alot of changes?
16:14:32 <dhellmann> we should review the audit list and open tickets for items that need to be done
16:14:33 <dhellmann> #link https://docs.google.com/spreadsheets/d/1MvXsg0XxPonJ8yAFSraIwHM940eAfoXhfBVRa6hN7MY/edit#gid=0
16:14:39 <dhellmann> harlowja_at_home: mostly hiding things that are public now
16:14:42 <dimsum_> dhellmann: i had some files that should probably belong in oslo.utils
16:14:50 <dimsum_> Files to be moved to oslo.utils
16:14:50 <dimsum_> ./openstack/common/fileutils.py
16:14:50 <dimsum_> ./openstack/common/imageutils.py
16:14:52 <dimsum_> ./openstack/common/versionutils.py
16:14:54 <dimsum_> ./openstack/common/xmlutils.py
16:15:21 <dhellmann> ah, yes, I think all of those were slated for other libraries, though
16:15:23 <harlowja_at_home> dhellmann, ah, hmmm, doesn't seem worthy of a whole spec
16:15:24 <beekneemech> Can somebody post a link to that etherpad quick?
16:15:41 <dimsum_> #link https://etherpad.openstack.org/p/kilo-oslo-library-proposals
16:15:46 <dimsum_> that one beekneemech?
16:15:51 <beekneemech> dimsum_: Yep, thanks
16:16:44 <dhellmann> the old wiki page is also useful input for that, although it lacks some of the details on specific filenames
16:16:45 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/GraduationStatus
16:17:12 <dimsum_> dhellmann: i still don't like too many copies of context.py's with its RequestContext and get_admin_context()
16:17:31 <beekneemech> dhellmann: I would tend to agree with harlowja_at_home.  Hiding stuff that shouldn't be public seems like just a normal part of the API cleanup for a graduation.
16:17:33 <dhellmann> dimsum_: context is already in oslo.log
16:17:44 <beekneemech> Unless you think there's something that would be contentious of course.
16:17:54 <dimsum_> dhellmann: others are using oslo-incubator's copy
16:18:12 <dimsum_> guess till oslo.log is released
16:18:14 <dhellmann> beekneemech, harlowja_at_home : I don't think much of this will be a surprise, so maybe I'll stage them as several commits and we can see how that goes.
16:18:21 <dhellmann> dimsum_: right
16:18:26 <harlowja_at_home> dhellmann, sounds good
16:18:46 <dhellmann> dimsum_: is it more than oslo.messaging?
16:19:30 <dhellmann> can I get a volunteer to look through the audit spreadsheet and open bugs for incomplete items?
16:19:35 <dimsum_> dhellmann: it was in middleware too by only one tiny method was used, i have a review pending to remove context.py from middleware
16:19:45 <dhellmann> dimsum_: ok
16:21:08 <beekneemech> dhellmann: I've been updating concurrency and I can take a look at serialization too.
16:21:13 <beekneemech> I suspect serialization is actually done though.
16:21:27 <dhellmann> beekneemech: thanks -- I added a couple of tasks to the bottom of the list
16:21:46 <dhellmann> oh, I see you have changes up for concurrency for those
16:22:13 <beekneemech> dhellmann: Yep, and they're mostly n/a for serialization.
16:22:19 <beekneemech> Except the delete from incubator one, which is also pending.
16:22:28 <dhellmann> I think the biggest thing is to make sure each lib has an API documentation section that only includes the parts of the library we want to make public
16:23:33 <dhellmann> nice. I'd like to have oslo.log and oslo.concurrency released before the summit, if you all think that's a reasonable goal.
16:23:58 <dimsum_> dhellmann: +1
16:24:42 <beekneemech> dhellmann: concurrency should be doable
16:24:45 <dimsum_> dhellmann: those 2 and middleware needs to get into global reqs too
16:25:02 <beekneemech> We need releases first though, right?
16:25:10 <dimsum_> so we can cleanup oslo-incubator
16:25:13 <dhellmann> yeah, we'll have to wait to add something until the release is done and the requirements freeze is lifted
16:25:42 <dhellmann> that should be happening soon, I hope
16:26:10 <dhellmann> well, actually, that's not likely to happen for a few weeks, based on the schedule I'm looking at
16:26:24 <dhellmann> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
16:26:43 <dhellmann> that gives us plenty of time to tidy up and have our releases ready, though
16:27:05 <dhellmann> speaking of in a few weeks...
16:27:07 <dhellmann> #topic planning for kilo
16:27:14 <dhellmann> I've mentioned before that we aren't using the old summit proposal tool this time around, so we will need to plan the summit sessions during our meetings, on the mailing list, and with specs.
16:27:20 <dhellmann> We have an etherpad we're using to track all of the topics, so we don't forget to talk about something important:
16:27:21 <dhellmann> #link https://etherpad.openstack.org/p/kilo-oslo-summit-topics
16:27:43 <dhellmann> I think it will be easier to talk about these things on the list, but we do have a few meetings between now and then. If you think your topic will need a lot of discussion, please start a mailing list thread.
16:28:15 <dhellmann> we will have 6-7 scheduled slots, about 2/3 of what we had in atlanta, so we will need to be judicious with how we use them
16:29:13 <dhellmann> are there any big topics people have thought of or heard mentioned that aren't already on this list?
16:29:49 <harlowja_at_home> dhellmann, jd__ should tooz be on that list?
16:30:18 <dhellmann> good question
16:30:32 <dhellmann> I didn't consider that very controversial. Are there details for us to work out?
16:31:17 <dimsum_> dhellmann: do we need a slot of next round of libs or can we work that out before hand?
16:31:54 <harlowja_at_home> dhellmann,  not likely controversial i guess, so maybe not needed
16:32:34 <dhellmann> dimsum_: heh, yeah, we should probably have a working session on that
16:32:36 * dhellmann head-slaps
16:32:59 <dimsum_> :)
16:34:48 <amrith> dhellmann, a request re: kilo planning
16:34:55 <dhellmann> I sent email to the list today about the specs repository being open for kilo, too, so as you propose topics keep in mind whether we will need a spec for the work.
16:35:10 <dhellmann> amrith: yes?
16:35:32 <amrith> dhellmann, would it be possible to consider the timing of project graduation and code migration in the next cycle
16:35:44 <dhellmann> amrith: in what sense?
16:35:45 <amrith> for example, with concurrency this cycle
16:35:56 <amrith> projects with downstream dependencies on oslo-incubator
16:36:03 <amrith> had changes that were gated on the graduation
16:36:13 <amrith> and with the impending deletion of code from o-i
16:36:22 <amrith> the changes that went into o.c can't make it to the downstream projects
16:36:25 <amrith> till they adopt o.c
16:36:34 <amrith> which won't happen till the next cycle
16:36:39 <amrith> therefore, in my specific case
16:36:41 <dhellmann> amrith: do you have a suggestion for how to improve that?
16:36:48 <amrith> yes
16:37:00 <amrith> would it be possible to have a period of overlap between o-i and the graduated project
16:37:05 <amrith> where code goes to both places?
16:37:16 <dimsum_> amrith: based on what we have seen, we can probably get rid of all code in oslo-incubator in next cycle
16:37:21 <amrith> optionally allow the code to go into o-i before you delete the files
16:37:26 <amrith> I understand
16:37:37 <beekneemech> I think amrith has a specific patch in mind.
16:37:41 <dhellmann> amrith: we did that this cycle, and ran into issues where incubated modules used others that had moved to the libraries
16:37:45 <amrith> but I think you know of the circumstances relating to the changes I submitted to o-i and o.c
16:37:52 <dimsum_> yep
16:37:52 <beekneemech> Where the change merged to o.c, but ran into feature freeze for incubator.
16:38:02 <dhellmann> yeah, the timing was bad on that change
16:38:07 <amrith> beekneemech, stated it succinctly
16:38:23 <amrith> dhellmann, yes, the timing was not conducive to merging down into trove
16:38:33 <amrith> even if the changes were allowed into o-i before the files were deleted
16:38:36 <amrith> taht would have sufficed
16:38:45 <amrith> I'd have been able to do the merge from o-i into trove
16:38:47 <amrith> for this cycle
16:38:52 <amrith> and we'll move to o.c for next cycle
16:38:55 <amrith> just a thought
16:39:08 <amrith> but if mine was a specific bad timing, let's not make an edifice for this edge case.
16:39:09 <amrith> thx
16:39:22 <dhellmann> amrith: yeah, I think for every variation of the timing and overlap I've been able to come up with there has been some negative side-effect :-/
16:39:47 <amrith> dhellmann, I see your point. lets err on the size of not having duplicated code and the possibilit of bad merges.
16:39:50 <amrith> I'll wait a cycle ;)
16:40:01 <dhellmann> amrith: we may have over-estimated the number of libs we would be able to successfully graduate for juno, since we have 2 incomplete ones
16:41:24 <dhellmann> amrith: several conditions aligned to cause that situation, but we *hope* it won't be as much of a problem as we move up the stack further
16:41:32 * dimsum_ knocks on wood
16:41:36 <dhellmann> heh
16:41:44 * amrith knocks on head
16:41:47 <dimsum_> lol
16:42:24 <amrith> dhellmann, it will certainly be less of an issue once we get to o.c ... thanks!
16:42:48 <dhellmann> amrith: yes, that's why we're prioritizing releasing the libs over everything else, fo rnow
16:43:22 <dhellmann> so, what's the best way to work out (and document) the decisions on https://etherpad.openstack.org/p/kilo-oslo-library-proposals ?
16:43:58 <dhellmann> some of them seem obvious, but some are different from what we planned before, so we should review them before we move ahead
16:45:25 <dhellmann> dimsum_: mailing list? meeting?
16:45:59 <beekneemech> dhellmann: Ultimately those will end up as specs, right?
16:46:19 <dhellmann> yeah, for the final documentation and review
16:46:43 <dhellmann> I'd like to avoid having the "local.py" issue again, this time around, though.
16:47:37 <beekneemech> Yeah, but that wasn't a discussion venue problem was it?  It was a "we don't know all the places this is being used" problem.
16:47:55 <dimsum_> dhellmann: either is ok
16:47:59 <dhellmann> partly, but also partly when we figured some things out I feel like we didn't write them down
16:48:21 <dhellmann> or maybe that's just my bad memory
16:48:42 <beekneemech> Heh, I was going to point out on your PTL mail that your actual platform for this cycle is "write things down", not "more of the same" :-P
16:49:05 <dhellmann> I had identified, I thought, oslo.local as a stand-alone library, and was talked out of it because I couldn't remember why. So that's on me, but how do we avoid it happening again?
16:49:19 <dhellmann> beekneemech: that's my TC position :-)
16:49:30 <dimsum_> beekneemech: lol
16:49:31 <beekneemech> dhellmann: Fair enough :-)
16:50:02 <dhellmann> or maybe just my personal mantra
16:50:19 <dhellmann> #topic review priorities for this week
16:50:21 <amrith> beekneemech, he also promised lower taxes
16:50:32 <dhellmann> he
16:50:53 <dhellmann> we mentioned oslo.log, oslo.concurrency, and pbr earlier
16:51:16 <beekneemech> Are there more oslo.log reviews since this morning?
16:51:20 <dhellmann> the analysis dims is doing is also a priority
16:51:26 <beekneemech> Because I think I approved them all. ;-)
16:51:30 <dhellmann> beekneemech: not now, but there will be when I write them
16:51:36 <beekneemech> ok
16:51:43 <dhellmann> and thanks for that :-)
16:51:58 <dhellmann> I'm sure harlowja_at_home would like some taskflow reviews
16:52:01 <dhellmann> what else do we have?
16:52:12 <harlowja_at_home> of course :)
16:52:45 <harlowja_at_home> if people are intersted look @ bottom of https://etherpad.openstack.org/p/TaskFlow-0.4 :)
16:52:49 * dimsum_ steps away from keyboard
16:53:14 <harlowja_at_home> ^ for a list of reviews that i've somewhat prioritized
16:53:24 <beekneemech> Guess dimsum_ really doesn't want to review taskflow ;-)
16:53:59 <harlowja_at_home> lol
16:54:12 <harlowja_at_home> run away!
16:55:41 * harlowja_at_home ok didn't really mean that, come back people
16:55:45 <dhellmann> heh
16:55:55 <beekneemech> :-)
16:56:12 <dhellmann> it sounds like we have the reviews covered, then
16:56:12 <dhellmann> #topic open discussion
16:56:19 <beekneemech> https://review.openstack.org/#/c/124451/1/oslo/concurrency/lockutils.py
16:56:29 <beekneemech> specifically moving the opts to a group
16:56:41 <beekneemech> I think we should make that standard policy for graduating libs.
16:56:50 <dhellmann> beekneemech: I like it
16:57:01 <dhellmann> we should be adding entry points for the oslo-config-generator at the same time
16:57:11 <beekneemech> Yep, did that too.
16:57:39 <harlowja_at_home> beekneemech, please if u get some time https://review.openstack.org/#/c/123257/ also :)
16:57:39 <beekneemech> So I can go ahead and add that to the graduation checklist?
16:57:53 <dhellmann> hmm. I see the set_defaults() function, and I wonder -- how do we handle that if we don't want the library to assume there is a global CONF object?
16:58:10 <beekneemech> dhellmann: I dunno, so I punted for now.
16:58:18 <dhellmann> beekneemech: yeah, I have the same problem for oslo.log
16:58:20 <beekneemech> harlowja_at_home: Okay, will try to take a look.
16:58:43 <beekneemech> dhellmann: I was thinking maybe provide a way to specify a non-global conf object and fall back to global if that isn't done?
16:59:18 <beekneemech> I wasn't sure about registration either - I know we're recommending not to register on import like lockutils does now.
16:59:31 <harlowja_at_home> beekneemech, that is basically moving the lock code to pylockfile, so seems relevant ;)
16:59:39 <dhellmann> beekneemech: I was thinking about requiring the arg, and letting the app pass the global. But we also want to call register_opts() at runtime, and I'm not sure you can call set_defaults() before register_opts().
17:00:27 <dhellmann> our time slot is over, so we should release the room
17:00:30 <dhellmann> thanks, everyone!
17:00:38 <beekneemech> dhellmann: For lockutils I don't want to require the conf object because we use it a lot of places.
17:01:00 * beekneemech moves to openstack-oslo.
17:01:06 <dhellmann> #endmeeting