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