16:00:12 <dhellmann> #startmeeting oslo
16:00:12 <openstack> Meeting started Fri Sep 12 16:00:12 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'oslo'
16:00:19 <dhellmann> who's around for the oslo meeting?
16:00:23 <kgiusti> o/
16:00:29 <viktors> o/
16:00:30 <jecarey> o/
16:01:29 <beekneemech> \o
16:01:43 <bknudson> hi
16:02:05 <dhellmann> dimsum_, zzzeek : ping
16:02:13 <dhellmann> viktors: ping
16:02:20 <viktors> dhellmann: pong
16:02:23 <dhellmann> our agenda:
16:02:23 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
16:02:24 <dimsum_> on my way o/
16:02:31 <dhellmann> #topic Review action items from previous meeting
16:02:39 <zzzeek> o/ though im on a flaky hotel wifi
16:03:19 <dhellmann> I have updated stevedore to build wheels, and I talked to ttx about the oslo.rootwrap release
16:03:33 <dhellmann> I think that's all we had from last time, based on http://eavesdrop.openstack.org/meetings/oslo/2014/oslo.2014-09-05-16.00.txt
16:03:40 <dhellmann> #topic Red flags for/from liaisons
16:04:05 <dhellmann> liaisons, are you running into issues locking down your release candidates?
16:05:10 <dhellmann> I'll take that as a no :-)
16:05:13 <harlowja_at_home> \o
16:05:14 <viktors> bknudson: have you seen this patch - https://review.openstack.org/#/c/120146/ ?
16:05:45 <bknudson> viktors: no, I'll put it on my list
16:05:52 <viktors> bknudson: thanks!
16:06:19 <dhellmann> any other news from or for liaisons?
16:06:47 <bknudson> not much going on due to feature freeze, rc
16:06:58 <dhellmann> ok, we have a couple of bugs in play, let's talk about those
16:06:58 <dhellmann> #topic lockutils bug
16:07:03 <dhellmann> #link https://bugs.launchpad.net/nova/+bug/1367941
16:07:03 <bknudson> can start back up again once kilo is opened
16:07:04 <uvirtbot> Launchpad bug 1367941 in nova "Able to aquire the semaphore used in lockutils.synchronized_with_prefix twice at the same time" [Medium,In progress]
16:07:09 <dhellmann> beekneemech, have an update?
16:07:37 <beekneemech> dhellmann: harlowja_at_home just proposed a fix for the releasing message not being logged when there's an exception raised.
16:07:51 <beekneemech> Other than that I think we're in good shape with that bug.
16:07:55 <dhellmann> #link https://review.openstack.org/121160
16:08:15 <dhellmann> it seems like I can change the priority from critical
16:08:30 <dhellmann> ah, that's been done since I loaded that page last :-)
16:08:31 <harlowja_at_home> can we just not use threads/eventlet anymore :)
16:08:40 <beekneemech> dhellmann: It was already, wasn't it?
16:08:54 <dhellmann> beekneemech: yep, I needed to reload from a few hours ago
16:08:56 <beekneemech> I think incubator may have still been critical this morning, but I dropped that already.
16:09:08 <dhellmann> beekneemech: it's unassigned, should I give it to you?
16:09:50 <beekneemech> dhellmann: Yeah, probably.
16:10:04 <dhellmann> done
16:10:30 <dhellmann> well, except lp is flaking out on me
16:10:32 <dhellmann> I'll do that later
16:10:48 <dhellmann> #topic sqlalchemy-migrate issue
16:11:06 <dhellmann> so yesterday we pushed through a release of sqlalchemy-migrate for an oslo bp, and that broke some things in nova's unit tests
16:11:28 <dhellmann> I think we've come to a consensus on the general approach to fix that after feature freeze
16:12:00 <dhellmann> the mailing list thread:
16:12:01 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/045840.html
16:12:11 <dhellmann> questions or comments on that?
16:12:15 <harlowja_at_home> do we want to get sqlalchemy-migrate into the gating process then? (i believe its not?)
16:12:33 <dhellmann> it's not an oslo library, and so far we've resisted the urge to adopt it because we really want people to stop using it
16:12:39 <harlowja_at_home> kk
16:12:48 <dhellmann> that's up for discussion, though, if we think it would make things better
16:13:20 <dhellmann> the tests that broke were unit tests, and we're not doing cross-project gating on those anyway, so I don't think that would have made the situation any better
16:13:39 <dhellmann> that cross-project testing is also still up for discussion for kilo
16:13:57 <dhellmann> ok, let's talk about where our release candidates stand
16:14:00 <dhellmann> #topic other RC-1 Work
16:14:10 <dhellmann> I've moved tracking out of the old etherpad:
16:14:11 <dhellmann> #link https://etherpad.openstack.org/p/juno-oslo-feature-freeze
16:14:19 <dhellmann> to launchpad:
16:14:20 <dhellmann> #link https://launchpad.net/oslo/+milestone/juno-rc1
16:14:31 <dhellmann> after *finally* getting the projects there cleaned up
16:15:03 <dhellmann> as bugs come in, we should be triaging and targeting them if they need to be fixed
16:15:05 <harlowja_at_home> is the pylockfile adoption still happening?
16:15:21 <dhellmann> that's in progress, yes, but it's not an rc-1 blocker
16:15:32 * harlowja_at_home has been following that goverance repo review
16:15:32 <harlowja_at_home> kk
16:15:42 <dhellmann> see also https://launchpad.net/oslo/+milestone/next-juno
16:15:44 <dhellmann> #link https://launchpad.net/oslo/+milestone/next-juno
16:16:21 <dhellmann> those can be "background tasks" that we complete but that won't block the release in any way
16:16:36 <dhellmann> most of those open bugs are related to documentation, for example
16:16:48 <YorikSar> dhellmann: I wonder why rootwrap daemon mode bp is in next-juno? It's already implemented
16:17:44 <dhellmann> YorikSar: I'll need to talk to ttx about how his release script works and whether we want to move that over to -rc1 when we close that milestone
16:18:03 <dhellmann> YorikSar: I was focusing on moving the in-progress or needs-to-be-done items over so we had a good list to work from
16:18:16 <YorikSar> dhellmann: There's another bp implemented in next-juno so we should do smth about that one too
16:18:28 <dhellmann> YorikSar: yep, I'll talk to ttx about that when the time comes
16:18:34 <ttx> dhellmann: I need to work on that script
16:19:23 <dhellmann> ttx: Should I retarget the finished items to our rc1 milestone to simplify the release? We are using next-juno for "post rc1" items
16:19:37 <dhellmann> non-blocking work, basically
16:20:10 <ttx> that's not how we discussed it
16:20:30 <dhellmann> no? I thought that's what we said.
16:20:31 <ttx> the idea, as I understood it, was to use next-juno and rename it when you release it
16:20:45 <ttx> since you know the version number then
16:21:26 <ttx> post-juno work should be in kilo, no ?
16:21:37 <dhellmann> I suppose we could just do that
16:21:55 <ttx> basically, there should be no "post-rc1 item in juno
16:22:07 <ttx> since rc1 is supposedly releaseable as final
16:22:08 <dhellmann> it's stuff like documentation, so I thought we might make it after our rc but before the overall rc was done
16:22:27 <dhellmann> ok, I see the sense in that
16:22:43 <dhellmann> I'll rearrange that stuff then and get rid of the rc1 tag and we'll just use next-juno
16:23:13 <ttx> maybe what you want is some x.y.z.aN milestone for your pre-rc
16:23:27 <ttx> and then next-juno for the "remaining work before release"
16:23:40 <ttx> if you want to track that differently
16:23:49 <dhellmann> yeah, I was trying to use a name that didn't include the version so we could have a unified view of the different projects
16:24:04 <ttx> dhellmann: ah! yeah, htat cross-project view is nice
16:24:11 <ttx> let me think about it a minute
16:24:18 <dhellmann> right, otherwise I go back to going insane trying to track everything :-)
16:24:59 <ttx> so if I understand correctly you want a milestone to track the work that will go in the last tag before the rc ?
16:25:17 <dhellmann> how about if I move everything in next-juno to next-kilo and then rename juno-rc1 to next-juno? that lets us have the unified view and correctly reflects the fact that the other work will come after the release
16:25:22 <dhellmann> yes, that's right
16:26:05 <ttx> why not use the last tag as the rc ?
16:26:29 <dhellmann> the last tag where?
16:26:36 <ttx> heh, this is confusing
16:26:39 <dhellmann> oh, you mean the version of the library?
16:27:31 <ttx> I mean, why do you need to track work for the "last tag before rc" separately from "work before rc"
16:27:42 <ttx> couldn't the last tag be the rc ?
16:27:59 <dhellmann> I think I'm being confusing by talking about 2 different RCs.
16:28:05 <dhellmann> Oslo will finish our rc1 on 18 Sept
16:28:21 <dhellmann> we have some documentation to write, and some other non-critical non-code things to do after that
16:28:30 <ttx> so yourc1 will be a collection of alpha tags on various libs, right ?
16:28:37 <dhellmann> yes
16:28:55 <ttx> ok, that's I think where the problem is, you call rc1 somethign taht's not a release candidate
16:29:04 <ttx> but more a development milestone
16:29:21 <dhellmann> should they be some other sort of tag, then?
16:29:23 <ttx> where it's still ok to change things after that
16:29:28 <dhellmann> should we just tag the final versions on 18 Sept
16:29:37 <dhellmann> well, just documentation
16:29:39 <bknudson> I thought we wanted non-alpha versions for the client releases?
16:29:50 <dhellmann> bknudson: yes, you're right, i forgot about that
16:29:54 <ttx> rigth, we want the final
16:30:11 <ttx> frankly at this stage it's simpler to just use a single milestone
16:30:17 <dhellmann> ok, so on 18 Sept we'll be tagging with the (hopefully) final versions as found on https://etherpad.openstack.org/p/juno-oslo-feature-freeze
16:30:29 <ttx> you use next-juno, target all work to it, when you tag a final you rename it
16:30:34 <dhellmann> ok
16:30:39 <dhellmann> I'll update launchpad
16:30:51 <ttx> IF shit happens, you can open a new next-juno and re-release it (bumping other projects requirements as needed)
16:31:01 <dhellmann> when I'm done, the work we have remaining for our release will be in https://launchpad.net/oslo/+milestone/next-juno
16:31:14 <dhellmann> that list is currently things we have already done or that need to happen for kilo
16:31:26 <dhellmann> and we'll just start our kilo cycle before everyone else, that's fine
16:31:34 <ttx> and post-juno work fgoes to next-kilo
16:31:38 <dhellmann> right
16:31:44 <dhellmann> ok, I'll fix that up by the end of the day today
16:32:20 <dhellmann> ok, sorry for the confusion on that everyone
16:32:39 <bknudson> for kilo the releases change back to alphas?
16:32:41 <dhellmann> so, looking at our current list on https://launchpad.net/oslo/+milestone/juno-rc1 -- are we missing anything there?
16:32:48 <dhellmann> bknudson: yes, under the new version series
16:33:56 <dhellmann> is everyone clear on the rc1 work now?
16:33:59 <ttx> dhellmann: it might still be useful at some point to have two different milestones, one for the next alpha tag, and one for the tag that will come after it... butwe can discuss that for kilo
16:34:19 <dhellmann> ttx: ok
16:34:39 <harlowja_at_home> dhellmann, so https://launchpad.net/oslo/+milestone/next-juno will be adjusted right, i can probably associate a few taskflow bugs that aren't in that list later today (i guess after the adjustment that ttx suggested?)
16:34:44 <ttx> for juno with one week left, next-juno = non-alpha versioned tag
16:34:57 <dhellmann> harlowja_at_home: yes
16:35:08 <harlowja_at_home> k, thx
16:35:10 <ttx> = probably the last juno release
16:35:31 * ttx disappears
16:35:38 <dhellmann> ttx: that works, and thanks
16:35:40 <ttx> sorry for the intrusion/mess
16:35:42 <ttx> :)
16:35:48 <dhellmann> no, thanks for fixing us up! :-)
16:35:56 <dhellmann> ok, moving on
16:35:57 <dhellmann> #topic Graduation status
16:36:04 <dhellmann> #info version number list at the bottom of https://etherpad.openstack.org/p/juno-oslo-feature-freeze
16:36:16 <dhellmann> we just went over this, but I'm a slave to the agenda
16:36:28 <dhellmann> on 18 sept we'll be tagging versions based on the list there
16:36:50 <dhellmann> dimsum_, is oslo.vmware going to be 1.0 ?
16:36:56 <dhellmann> oh, I see you just updated the pad
16:37:01 <dimsum_> 0.6.0
16:37:02 <dimsum_> y
16:37:12 <dhellmann> I moved it down to the pre-release list
16:37:19 <dimsum_> cool
16:37:36 <dhellmann> and I updated oslo.db to be 1.0, since it's in use
16:37:59 <viktors> ok
16:38:24 <dhellmann> we need to work on getting our libraries that are in use in the other projects up to 1.0 status by the end of kilo, or have a reasonablly detailed set of reasons why we can't
16:39:01 <dhellmann> be thinking about that as we start planning kilo
16:40:04 <dhellmann> I'm anticipating a couple of pre-releases between now and monday for oslo.db, oslo.vmware, and pbr -- is there anything else that needs a release to allow for unit tests before the final releases on next thursday?
16:40:43 <dhellmann> #action dhellmann review all libs for unreleased changes that need to go out on monday
16:41:13 <dhellmann> #topic open discussion
16:41:25 <dhellmann> that's all of the formal agenda, does anyone have anything else they need to bring up?
16:42:03 <bknudson> nope
16:42:06 <harlowja_at_home> nopers
16:42:11 <zzzeek> lots on my mind but nothing good for here...
16:42:11 <rpodolyaka> guys, do I understand correctly,that we should merge these last transifex/global-requrements sync changes asap?
16:42:37 <dhellmann> rpodolyaka: yes, we need to do that before cutting final versions of the libs
16:42:56 <rpodolyaka> cool, that was my understanding too
16:43:04 <dhellmann> I won't release new alphas if those are the only changes I see in a project, but we want the requirements up to date by thursday
16:43:07 <bknudson> if you want it merged by monday better get started!
16:43:08 <YorikSar> dhellmann: Will alphas be tagged on Sep 18 as well?
16:43:19 <rpodolyaka> bknudson: indeed :(
16:43:25 <zzzeek> newb q: is it the general case that random reviews coming in for oslo.db are definitely only for kilo?
16:43:27 <viktors> bknudson: :-D
16:43:29 <dhellmann> rpodolyaka: and if you have +2, you can just approve translation and requirements updates -- my policy is we don't argue with those changes in oslo
16:43:54 * dimsum_ nods
16:43:55 <rpodolyaka> dhellmann: ack
16:44:06 <dhellmann> YorikSar: if we need any other alphas, those will happen between now and monday. We will use final version numbers for everything on 18 sept
16:44:29 <dhellmann> zzzeek: yes, at this point, only bugs blocking other projects' releases should be merged
16:44:33 <zzzeek> dhellmann: great
16:44:46 <dhellmann> there's no need to -2 them, just leave them out there for now
16:45:02 <zzzeek> dhellmann: i was -2’ing things that are in conflict with my own patches
16:45:11 <dhellmann> ok, that's different
16:45:29 <rpodolyaka> btw, that reminds of https://review.openstack.org/#/c/110170/29 / https://review.openstack.org/#/c/120923/
16:45:34 <dhellmann> other projects do make a point of using -2 at this point to signal to contributors why something isn't going to merge, but we don't usually have enough traffic to worry about that (at least not yet)
16:45:37 <rpodolyaka> which one of those we should merge
16:45:43 <zzzeek> rpodolyaka: yup thats the one
16:45:45 <YorikSar> dhellmann: But what about oslo.concurrency? It's moving slowly (mostly because of me) and seems not ready for release.
16:45:52 <zzzeek> rpodolyaka: https://review.openstack.org/#/c/110170/29 is good, but its fine for kilo
16:45:55 <dhellmann> rpodolyaka: at this point, probably neither
16:46:13 <zzzeek> i dont think we shoudl be changing any of this stuff until then
16:46:15 <dhellmann> I haven't had a chance to look at them in detail to pick between them
16:46:31 <rpodolyaka> so zzzeek's change is more like a refactoring
16:46:35 <rpodolyaka> and the other one is a bug fix
16:46:41 <zzzeek> dhellmann: OK well waht of the blueprint https://review.openstack.org/#/c/117335/ ?
16:46:53 <rpodolyaka> the bug itself is not critical though
16:46:55 <zzzeek> rpodolyaka: their fix is just little cleanup stuff
16:46:58 <zzzeek> rpodolyaka: its not a bug
16:47:09 <dhellmann> zzzeek: that will need to be resubmitted as a kilo blueprint when we open those up, after the releases are all done
16:47:13 <zzzeek> rpodolyaka: its cleanup that my refactor blows over, so i dont seethe need to waste time rearranging deckchairs
16:47:47 <zzzeek> this is waht i mean, ppl keep sumitting little nit fixers to the test system even though we’re in FF and all that
16:47:54 <zzzeek> why are they doing that now?
16:48:08 * dhellmann shrugs
16:48:23 <bknudson> it's better to have the changes in gerrit rather than on your pc
16:48:26 <bknudson> in case you get hit by a bus
16:48:37 <zzzeek> im mostly doing test connectivity and then i want to get into the EngineFacade stuff next
16:48:40 <dhellmann> bknudson: fair point
16:48:46 <zzzeek> so nobody touch any of that!
16:48:50 <dhellmann> heh
16:48:54 <rpodolyaka> :)
16:49:17 <zzzeek> nova actually runs a single operation across multiple connections b.c. they are not using the session correctly
16:49:21 <harlowja_at_home> *and nobody please get hit buy a bus*
16:49:23 <bknudson> if you really want your changes to go first, then can rebase the other change on yours
16:49:27 <dhellmann> harlowja_at_home: ++
16:50:18 <dhellmann> ok, I think we're done for today. take the extra 10 minutes to review one of our rc1 patches, please!
16:50:30 <zzzeek> lates
16:50:50 <dhellmann> #endmeeting