21:00:59 <ttx> #startmeeting project
21:01:00 <openstack> Meeting started Tue Apr  1 21:00:59 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:03 <openstack> The meeting name has been set to 'project'
21:01:07 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:01:09 <dolphm> o/
21:01:18 <ttx> #topic Missing RC1s
21:01:25 <david-lyle> o/
21:01:30 <ttx> At this point we are only missing RC1s for Trove and Swift
21:01:45 <notmyname> last few things being resolved in swift
21:01:46 <devananda> o/
21:01:50 <ttx> Trove's ETA is tomorrow, Swift ETA is Thursday
21:02:11 <ttx> in all cases we'd crreate MP branches this week to get depfreeze unfrozen on master
21:02:44 <ttx> #topic Potential RC2 windows
21:02:58 <ttx> During the 1:1s we looked at icehouse-rc-potential bugs
21:03:12 <ttx> We'll let the RC1 get some more testing mileage
21:03:18 <hub_cap> heyo
21:03:29 <ttx> and start opening ad-hoc RC2 windows as needed starting Thursday
21:03:39 <ttx> we have a few translations issues that need to be fixed
21:04:38 <ttx> Try to limit use of the icehouse-rc-potential tag to release-critical issues that may make a RC respin warranted
21:05:00 <ttx> we can always include MORE fixes once the window is opened, just lookign at the bugs that got fixed in master in the mean time
21:05:31 <stevebaker> now you tell me ;)
21:05:34 <ttx> I'll keep an eye on the  icehouse-rc-potential lists and we'll be in touch to get those RC windows opened
21:05:41 <markmc> things punted til later are moved to icehouse-backport-potential, right?
21:06:07 <ttx> markmc: yes, this one can be used more as a "makes sense to backport this one" meaning
21:06:15 <markmc> cool
21:06:31 <ttx> whereas icehouse-rc-potential is more "hmm... we really can't release with that in"
21:06:48 <ttx> other questions on that ?
21:07:05 <devananda> ttx: is the process just to add the icehouse-rc-potential tag on a bug?
21:07:18 <ttx> devananda: hmm.. yes ?
21:07:28 <ttx> sounds like a tricky question
21:07:36 <ttx> hope I answered right
21:07:39 <devananda> :)
21:07:52 <ttx> #topic Depfreeze exceptions
21:08:00 <ttx> #link https://review.openstack.org/#/c/84030
21:08:13 <ttx> This one is about skipping pbr 0.7 because it's broken on Windows
21:08:23 <ttx> The problem is we are under depfreeze, we had 0.7 around before depfreeze and this affects everyone (unlike, say, happybase)
21:08:33 <ttx> So it seems to be precisely the type of bumps depfreeze was meant to prevent
21:08:49 <ttx> Since the current spec (>=0.6) doesn't prevent the use of 0.8 on Windows setups, I'm not exactly sure why this would be *needed*
21:08:58 <ttx> Am I missing something ?
21:09:16 <dhellmann> no, I had a similar reaction
21:09:54 <markmc> I guess someone could have the requirements satisfied with 0.7 and it would break windows
21:10:00 <markmc> but, obscure to say the least
21:10:09 <markmc> agree it's not worth ruling out 0.7
21:10:35 <markmc> is it just because it's windows, though?
21:10:39 <ttx> if the thing was capped to <=0.7 I would agree we should uncap it
21:10:55 <ttx> but >=0.6 shoulds work for everyone
21:10:59 <dhellmann> markmc: yes, it was just windows, though I don't remember the details
21:11:02 <ttx> just use 0.8 if you like it better
21:11:10 <russellb> if 0.7 was broken on linux, i bet we'd change it to exclude 0.7 ...
21:11:20 <markmc> I mean, if 0.7 was broken on fedora but working on ubuntu, would we approve this?
21:11:41 <markmc> maybe not worth wasting time on the hypothetical
21:11:44 <russellb> maybe that's fine, i don't know
21:11:45 <russellb> yeah.
21:11:52 <markmc> if we're happy saying windows is second class citizen
21:11:55 <russellb> right
21:12:03 <russellb> i am :)
21:12:04 <ttx> markmc: I don't think we'd approve something that would shift the work from Fedora to Ubuntu
21:12:15 <sdague> well, I think the point of requirements is here is a valid range of choices
21:12:24 <ttx> here I'm not even sure we make it difficult for windows
21:12:27 <russellb> right, the question is, would we consider 0.7 valid if it broke all linux
21:12:39 <russellb> flip the situation around
21:12:40 <ttx> russellb: it wouldn't pass the gate, surely
21:12:48 <ttx> ...
21:12:56 <russellb> pretend it did, somehow :)
21:13:04 <russellb> just trying to flip the situation
21:13:06 <ttx> well, it's a bit of the root of the issue
21:13:09 <sdague> russellb: if it did, I honestly don't think we'd black list it
21:13:22 <sdague> I am sure there are plenty of non working versions in the requirements ranges
21:13:29 <sdague> we don't black list them all
21:13:36 <russellb> OK, guess all I think markmc was starting to say was "are we making this decision based on "well, it's just windows" ?"
21:13:36 <sdague> like sqla 0.9.0 doesn't actually work
21:13:51 <markmc> we do sometimes blacklist, though
21:13:56 <sdague> markmc: we do sometimes
21:13:57 <ttx> russellb: no. We are amking this decision as "well, it's past depfreeze"
21:14:05 <sdague> mostly if it's the only way through the gate
21:14:07 <russellb> OK, then it's all good
21:14:08 <markmc> meh - maybe let's have this debate when we have something that has real practical problems :)
21:14:17 <jeblair> ttx: yeah, i keep re-reading your original problem statement, and i agree it doesn't seem like there is a problem; the requirements we specify include working versions for all platforms
21:14:24 <ttx> I just wanted to make sure I wasn't overlooking something
21:14:25 <russellb> i think it's fine
21:14:46 <markmc> sorry for the rabbit hole
21:14:59 <russellb> they're fun sometimes
21:15:01 <ttx> I'm pretty sure that's not the onlt dep you need to bump IN YOUR DISTRO to make it work seamlessly with your system
21:15:15 <ttx> as long as it's in the range we set...
21:15:25 <ttx> we don't prevent them from using 0.8
21:15:27 <dhellmann> is this worth a release note?
21:15:41 <ttx> dhellmann: maybe
21:16:01 <russellb> how committal
21:16:04 <ttx> #action ttx to add windows pbr0.8 adherence to release notes
21:16:09 <dhellmann> how do people install openstack stuff on windows? pip?
21:16:14 <ttx> russellb: better ?
21:16:18 <russellb> ha, sure
21:16:27 <russellb> dhellmann: i have no idea.
21:16:34 * dhellmann hopes not pip
21:16:47 <ttx> alexpilotti: you don't happen to be around, do you ?
21:16:56 <russellb> he's active in -nova right now
21:17:10 * russellb pings in there
21:17:20 <ttx> oh, cool
21:17:42 <jeblair> also, i don't think we have an official support policy for windows
21:17:44 <alexpilotti> russellb: hi
21:17:45 <ttx> alexpilotti: we were looking at your depfreeze exception at https://review.openstack.org/#/c/84030
21:18:04 <ttx> looks like the current range >=0.6 would be compatible with windows using pbr0.8 ?
21:18:25 <alexpilotti> ttx: only 0.7 is flawed
21:18:29 <ttx> so we could avoid breaking distros that only have 0.7 by not doing anything
21:18:47 <ttx> alexpilotti: then what ? Just use 0.8
21:19:07 <russellb> alexpilotti: key point being the stated requirement doesn't prevent the use of 0.8
21:19:15 <russellb> so trying to decide if a change is needed or not (and we think not)
21:19:27 <alexpilotti> ttx: yeah of course, that's why teh patch is >= 0.6,!=0.7 :-)
21:19:34 <ttx> the problem is... we froze dependencies a week ago so that distros can enter their own freeze periods
21:19:51 <ttx> forcing them to bum to 0.8 just for a bug they don't encounter... is weird
21:20:15 <ttx> if this was out of depfreeze period i would accept it right away
21:20:30 <alexpilotti> russellb ttx: we distribute anyway the installer with 0.8, it's more for users that incidentally have already 0.7
21:20:52 <alexpilotti> and might wonder why nothing works anymore, as the error is not trivial to identify
21:20:55 <ttx> alexpilotti: we were thinking of documenting the prb0.8 adherence in the release notes
21:21:01 <russellb> sounds like if you already have this taken care of with the installer most people use, anyone affected is an incredibly small number
21:21:07 <alexpilotti> ttx: fair enough for me!
21:21:12 <dhellmann> russellb: +1
21:21:22 <russellb> alexpilotti: thanks for joining
21:21:32 <alexpilotti> thank you guys
21:21:34 <ttx> alexpilotti: cool. And we'll push the bump to 0.8 as soon as we unfreeze, which should be Friday
21:21:53 <alexpilotti> ttx perfect
21:21:56 <ttx> #topic Seeking Oslo liaisons
21:22:02 <ttx> #link https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
21:22:07 <ttx> dhellmann: floor is yours
21:22:42 <dhellmann> for juno we are going to formalize the plan jogo came up with for syncing to nova in icehouse, and ask each project to provide a point of contact and helper
21:22:59 <dhellmann> we would like to have them in place before the summit, since they may want to attend some oslo sessions
21:23:13 <dhellmann> so please ask your teams to volunteer -- at least one person per project
21:23:30 <jogo> dhellmann: ++, I'll volunteer for nova
21:23:43 * russellb done
21:23:45 <russellb> thanks jogo :-D
21:24:01 <dhellmann> as I said in my ptl candidacy note, I hope this helps with some of the dependency issues we encountered late in the cycle, for which I didn't have a lot of visibility
21:24:10 <dhellmann> thanks jogo! please add your details to that wiki page :-)
21:24:28 <dhellmann> that's all I have, unless anyone has questions?
21:24:44 <ttx> #info please volunteer one person per project for https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
21:24:57 <russellb> dhellmann: nice work on the plan for juno :)
21:25:03 <dhellmann> russellb: thanks :-)
21:25:04 <jgriffith> dhellmann: I'll wait til I see you in Atl for my questions
21:25:04 <ttx> #topic Tracking Oslo bugs as they relate to other projects
21:25:11 <ttx> dhellmann: you again!
21:25:12 <dhellmann> me again
21:25:17 <jogo> dhellmann: done
21:25:43 <dhellmann> so, we had some cases where bugs in other projects were reported against those projects when the changes needed to be made in oslo
21:25:53 <dhellmann> and then when the bug was moved to oslo, the other project was removed
21:26:06 <dhellmann> that made it hard for us to know who had the issue, or how important it was to fix
21:26:28 <markmc> these are oslo-incubator bugs? or library bugs?
21:26:32 <dhellmann> I don't have an answer for this one, so I'm asking for suggestions -- we can do that out of the meeting, but I wanted people to think about it
21:26:35 <dhellmann> markmc: both
21:26:46 <jogo> hopefully the liasons can help with that
21:26:52 <russellb> seems to make sense for incubator bugs to still be applied to the original project too
21:26:55 <markmc> IMHO, the answer would be different for both ... no?
21:27:04 <markmc> what russellb is saying :)
21:27:11 <dhellmann> jogo: yes, I hope so
21:27:11 <russellb> for libraries, move the bug, but perhaps note that it was discovered via nova or whatever
21:27:24 <dhellmann> russellb: +1, but I wasn't sure if that would mess up tracking
21:27:26 <markmc> or just mark as Invalid in Nova rather than remove it
21:27:34 <russellb> markmc: even better, +1
21:27:39 <ttx> dhellmann: nothing can mess up tracking. nothing
21:27:42 <russellb> nothing!
21:27:54 <dhellmann> yeah, I like marking invalid, because then we can still have the priority set
21:28:01 <ttx> although... 10 tasks on a bug will make it uneditable.
21:28:10 <ttx> apart from that, nothing
21:28:16 <russellb> though for these cases, we're talking about 2 instead of 1
21:28:30 <dhellmann> ttx: well, if we have 2 projects marking something as critical, I'm not sure we need *everyone* listed
21:28:31 <ttx> russellb: right. nothing then
21:28:32 <russellb> and project "set launchpad on fire" is in progress :)
21:28:44 <ttx> almost there !
21:28:45 <markmc> for the oslo-incubator cases, though ...
21:28:49 <markmc> we can get over 10 in those
21:28:53 <russellb> markmc: true
21:28:56 <russellb> but that's reality
21:29:00 <markmc> right
21:29:00 <russellb> it's important to track the flow of the fix
21:29:07 <russellb> always have the launchpad email interface
21:29:11 <russellb> or complain to ttx
21:29:12 <ttx> jeblair: we should have made a Storboard 1.0 announcement for today
21:29:18 <bnemec> The solution there is less copying, more graduating.
21:29:22 <dhellmann> I hope as we move code out of the incubator, that will lower the number of projects syncing
21:29:23 <russellb> ttx: skip to 2.0
21:29:25 <ttx> jeblair: with proxyredirect to LP
21:29:33 <dhellmann> a lot of them use the low-level libs, but not higher level ones
21:29:41 <jeblair> ttx: hehe :)
21:29:43 <dhellmann> bnemec: +1
21:30:10 <dhellmann> ok, so if we agree to use "invalid" and set a priority, I think that will help us with planning in oslo
21:30:22 <ttx> dhellmann: sounds good
21:30:23 <russellb> for the library cases?  sure
21:30:26 <dhellmann> and that should help us figure out what issues other projects are having that we need to give a high priority
21:30:46 <dhellmann> russellb: right, and for the incubator it needs to wait to be closed until the sync is done
21:31:03 <russellb> might want to document this on the bug triage wiki page
21:31:06 <dhellmann> #action dhellmann write up guidelines for tracking bugs against oslo libs and incubator
21:31:14 <ttx> dhellmann: done?
21:31:14 <russellb> https://wiki.openstack.org/wiki/BugTriage
21:31:21 <dhellmann> russellb: thanks
21:31:23 <dhellmann> ttx: yes
21:31:24 <ttx> #topic Red Flag District / Blocked blueprints
21:31:28 <markmc> dhellmann turning into a wiki page generating machine
21:31:30 <markmc> dhellmann, nicely done
21:31:38 <dhellmann> markmc: write down all the things
21:31:42 <ttx> morganfainberg: you had an issue to raise iirc
21:31:53 <dhellmann> I think we just resolved that
21:31:53 <morganfainberg> ttx, o/
21:32:04 <ttx> bug 1279000
21:32:06 <uvirtbot> Launchpad bug 1279000 in oslo "db migrate script to set charset=utf8 for all tables" [High,Fix committed] https://launchpad.net/bugs/1279000
21:32:06 <ttx> ?
21:32:18 <dhellmann> we're going to change oslo.db to ignore the table that lists the migrations
21:32:29 <morganfainberg> so it appears that in some cases (e.g. unless the db is created with the correct charset or my.cnf is changed) causes issues with migrations to fail
21:32:53 <morganfainberg> ttx, that is the original bug, but the sanity check needs to ignore the migrate_version table
21:33:13 <ttx> https://bugs.launchpad.net/glance/+bug/1279000/comments/12
21:33:14 <uvirtbot> Launchpad bug 1279000 in oslo "db migrate script to set charset=utf8 for all tables" [High,Fix committed]
21:33:26 <ttx> comment 12 talks about the issue spreading to keystone
21:33:30 <morganfainberg> we can fix this easily and ignore that table, but there is the case that anyone using the openstack common migration module will need to be updated for RC.
21:33:52 <morganfainberg> or alternatively we can document saying that the DBs must be created with the utf8 charset
21:33:53 <morganfainberg> the latter is sub-wonderful
21:34:11 <morganfainberg> but otherwise any/all projects could be affected by this issue if they're using that oslo module
21:34:30 <ttx> any idea which projects are affected ? All of them ?
21:34:43 <ttx> Glance apparently dodged the bullet on that bug
21:34:48 <ttx> markwash: ^
21:34:53 <morganfainberg> ttx, unsure, i just duplicated this for keystone about 20 minutes ago
21:35:10 <dhellmann> ttx: glance is using the feature we added to turn off that check
21:35:28 <ttx> dhellmann: so we need to spread that same fix to all other projects ?
21:35:44 <dhellmann> ttx: no, we need a new fix to ignore this one table and to spread that
21:35:52 <morganfainberg> dhellmann, ++
21:35:54 <ttx> oh, ok
21:36:10 <dhellmann> I'll work on a patch tomorrow, unless morganfainberg or bnemec beat me to it
21:36:22 <morganfainberg> dhellmann, i'll see what i can do today.
21:36:30 <ttx> Looks like we could use a NEW bug to track work on that
21:36:33 <dhellmann> morganfainberg: ok, that lets bnemec and me approve so that's good
21:36:38 <bnemec> +1
21:36:42 <ttx> because the current one has olso and glance all fixed
21:36:47 <dhellmann> ttx: good point
21:36:53 <morganfainberg> ttx, i'll file the bug in the next couple minutes and we'll need to figure out which projects are using this.
21:37:00 <bnemec> Yeah, and this is kind of a different issue.
21:37:02 <devananda> dhellmann: is this specific to sqlalchemy-migrate?
21:37:14 <dhellmann> devananda: I'm not certain
21:37:14 <ttx> morganfainberg: yes, make it icehouse-rc-potential and add atsks for all affected projects
21:37:32 <morganfainberg> devananda, if alembic does the same thing, there is code that does the same check
21:37:36 <ttx> the other OMG bug would be bug 1299349
21:37:37 <uvirtbot> Launchpad bug 1299349 in neutron "upstream-translation-update Jenkins job failing" [High,In progress] https://launchpad.net/bugs/1299349
21:37:40 <morganfainberg> devananda, just alembic specific
21:37:51 <markwash> it seems like glance needs this fix in its oslo db as well, since its not normal to ignore the utf8 charset check. . no?
21:37:58 <ttx> also affects lots of projects
21:38:03 <dhellmann> morganfainberg: let's go ahead and add alembic's migration tracking table to your fix
21:38:04 <morganfainberg> devananda, i'll verify if alembic has this issue or not and address it in the same fix.
21:38:12 <bnemec> markwash: You'll need it when you turn on utf8 checking.
21:38:13 <devananda> morganfainberg: thanks
21:38:23 <morganfainberg> devananda, well i'll verify and fix the same way and tag you guys in if needed.
21:38:27 <bnemec> For Icehouse Glance should be okay though.
21:38:32 <markwash> bnemec: it is on by default IIUC
21:38:35 <ttx> morganfainberg: ping me with bug number when you have it
21:38:42 <morganfainberg> ttx, sounds good.
21:38:44 <ttx> morganfainberg: and thanks for helping coordinate that one
21:38:47 <dhellmann> markwash: I thought you guys were turning it off in your manager?
21:39:03 <markwash> dhellmann: we have an option to turn off the utf8 charset check
21:39:10 <devananda> morganfainberg: quick local check shows ironic's tables as utf8, but alembic_version is latin1 :(
21:39:14 <markwash> the option defaults to False which means we still run the check
21:39:17 <dhellmann> markwash: oh, ok, I thought you were just turning it off all the time
21:40:14 * dhellmann is going to run out of battery soon
21:40:17 <ttx> OK, let's continue this off-meeting. Any other OOPS! bug ?
21:40:24 <ttx> Any other inter-project blocked work that this meeting could help unblock ?
21:40:33 <morganfainberg> devananda, thanks for the check will make sure you're tagged and alembic check is fixed the same way
21:40:47 <dhellmann> morganfainberg: thanks
21:41:02 <devananda> ttx: you mentioned i18n stuff earlier
21:41:23 <devananda> ttx: i think ironic was afected by the same issues. I posted a few hours ago with some notes on what we did to resolve it
21:41:30 <devananda> in case that's helpful to other projects
21:41:42 <ttx> devananda: cool. link to post?
21:42:01 <sdague> there is an fyi to the group, the clean log enforcement has now been added to the gate (which was talked about a few weeks back).
21:42:17 <devananda> #link http://lists.openstack.org/pipermail/openstack-dev/2014-April/031572.html
21:42:18 <sdague> the allowed dirty list is pretty long at this point - https://github.com/openstack/tempest/blob/master/tools/check_logs.py#L33-L57  but it's a start
21:42:41 <ttx> #info clean log enforcement has now been added to the gate
21:42:52 <ttx> #topic Incubated projects
21:43:02 <ttx> ironic has its RC1 out now
21:43:07 <devananda> \o/
21:43:12 <ttx> marconi is almost there
21:43:29 <ttx> SergeyLukjanov: how far is sahara ?
21:43:35 <SergeyLukjanov> sahara rc1 should be on Thu as planned
21:43:39 <SergeyLukjanov> https://launchpad.net/sahara/+milestone/icehouse-rc1 looks fine
21:44:11 <ttx> SergeyLukjanov: so, when you're ready...
21:44:23 <ttx> you need to push a version bump to open juno
21:44:36 <ttx> SergeyLukjanov: setup.cfg must be bumped to 2014.2
21:44:47 <SergeyLukjanov> ttx, I already have one in WIP
21:44:53 <ttx> example: https://review.openstack.org/#/c/83198/
21:44:56 <ttx> Oh, cool
21:45:03 <ttx> So when you're ready, approve that one
21:45:11 <ttx> and ping me when it merges
21:45:41 <ttx> then if you want to do a RC2 you can ping me or create the milestone yourselves
21:45:42 <SergeyLukjanov> ttx, any you'll tag rc1 / create m-p after it?
21:45:49 <ttx> SergeyLukjanov: yes
21:46:00 <SergeyLukjanov> ttx, ok, thx
21:46:22 <ttx> other questions ?
21:46:23 <SergeyLukjanov> ttx, I hope to be ready for it on Thu afternoon (in our tz)
21:46:31 <ttx> I like our tz
21:46:37 <ttx> #topic Open discussion
21:46:43 <ttx> Anything, anyone ?
21:47:17 <ttx> Note that the deadline for submitting "Other projects" and "Cross-project workshops" sessions suggestions was advanced to April 10
21:47:26 <ttx> #info deadline for submitting "Other projects" and "Cross-project workshops" sessions suggestions was advanced to April 10
21:47:54 <ttx> so that we can give early answers
21:48:30 <ttx> ok, if nobody has anything else to mention...
21:48:38 <morganfainberg> ttx, https://bugs.launchpad.net/ironic/+bug/1301036
21:48:40 <uvirtbot> Launchpad bug 1301036 in oslo "openstack.common.db.sqlalchemy.migration utf8 table check issue on initial migration" [Undecided,New]
21:49:42 <ttx> morganfainberg: thx!
21:51:41 <ttx> #endmeeting