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