21:02:46 <ttx> #startmeeting project
21:02:47 <openstack> Meeting started Tue Jan 14 21:02:46 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:51 <openstack> The meeting name has been set to 'project'
21:02:52 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:01 <ttx> #topic Icehouse-2 / 1.12.0 progress
21:03:10 <ttx> We've been looking at progress during the 1:1s
21:03:15 <hub_cap> hey
21:03:19 <ttx> Most projects are behind and need to defer a lot of things
21:03:23 <dolphm> (o/)
21:03:33 <ttx> At first glance I'd say some combination of holidays + slow gating affected our velocity
21:03:46 <ttx> We'll definitely need to go through some analysis and then reality checks as we plan the i-3 contents
21:03:58 * markmcclain2 is on flaky connection
21:04:05 <ttx> Anyway, this week if you're aware of some i2-targeted blueprint that won't make it, just defer it
21:04:17 <ttx> That will help convey the right information to people who consume that roadmap information
21:04:22 <stevebaker> ttx: can you confirm the i-2 dates?
21:04:26 <ttx> And also let you focus review resources on stuff that's likely to make it
21:04:38 <ttx> stevebaker: sure. We'll cut branches by EOD on Tuesday
21:04:43 <russellb> https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
21:04:44 <ttx> I'll be in UT by then
21:05:02 <ttx> so EOD migth actually mean EOD in mountain time
21:05:15 <russellb> ski trip?
21:05:29 <ttx> foundation team thing
21:05:34 <russellb> "meeting"
21:05:38 <ttx> "thing"
21:05:51 <ttx> stevebaker, hub_cap: got enough time to clean up your i-2 pages ?
21:05:56 <jgriffith> party
21:06:02 <stevebaker> ttx: making good progress
21:06:04 <hub_cap> ttx i did a bit of cleaning w/o asking people :)
21:06:13 * ttx checks out
21:06:48 <ttx> hub_cap: looks good
21:06:56 <ttx> stevebaker: wash, rinse, repeat :)
21:07:05 <stevebaker> yup :)
21:07:16 <ttx> Other questions about upcoming milestone ?
21:07:52 <devananda> ttx: none here. I'll bump a few BP this week
21:08:15 <ttx> #topic Log config option (dhellmann)
21:08:23 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/024205.html
21:08:31 <ttx> dhellmann: care to introduce the topic ?
21:08:39 <dolphm> l7 ulop;[']
21:08:42 <dhellmann> log translations are coming back, and this ML thread is about a config option to turn on a second log using a non-default locale
21:08:48 * dolphm wipes off keyboard
21:08:53 <dhellmann> I would prefer that we not add this option, because I think it's not going to be used much.
21:09:15 <dhellmann> Before I just veto it, I wanted to see if any other projects were expecting to have this feature easily enabled, vs. using the logging.conf setup file
21:09:35 <stevebaker> We've started getting reviews which have _(...) log messages. I'd like to know if there is a policy on i18n logging
21:09:46 <dhellmann> yes!
21:09:52 <dhellmann> _() is fine for now
21:10:01 <stevebaker> ok
21:10:07 <dhellmann> we are going to be landing patches to support different domains for different log levels
21:10:14 <dhellmann> the translators asked for that, and we may just make i2
21:10:30 <markmc> IMO, we shouldn't be translating log messages until we can put them in a separate translation domain
21:10:37 <markmc> and logs in multiple languages seems a bit bong
21:10:48 <jgriffith> markmc: +1
21:11:02 <markmc> dhellmann, cool on different domains
21:11:06 <markmc> dhellmann, hadn't seen that
21:11:11 <dhellmann> #link https://review.openstack.org/#/c/65518/
21:11:12 <dolphm> most of keystone's log messages go through _()
21:11:21 <dhellmann> #link https://review.openstack.org/#/c/65519/
21:11:41 <devananda> all of ironic's go through _(), fwiw. we rejected a patch from oslo a few weeks ago because it didn't
21:11:42 <ttx> dhellmann: sounds liek corner use case to me, if possible through logging.conf that sounds like good enough
21:11:50 <dhellmann> dolphm: _() will be reserved for exceptions and other non-log content in the future, with _LE, _LD, etc. used for log messages
21:11:52 <markmc> ok, so _LD(), _LI() etc. instead of just _L()
21:12:02 <dhellmann> markmc: yeah
21:12:12 <dhellmann> I still need to make the changes in -infra to extract the catalogs separately
21:12:27 <dhellmann> but I need a project with the things intact to test that, so chicken-and-egg meet CI
21:13:01 <dhellmann> ok, I'm not hearing any support for this new option, so I'll just nix it and propose the sample config file
21:13:01 <dolphm> markmc: dhellmann: is there some doc / wiki i can refer to on best practices there?
21:13:10 <dhellmann> dolphm: still on my todo list
21:13:21 <dhellmann> I'll be making an announcement on the ML when it's ready to be used
21:13:33 <dolphm> dhellmann: cool
21:14:16 <dhellmann> I'm ready to move on unless anyone has anything else on this
21:14:27 * jd__ votes for logging.conf
21:14:36 <ttx> +1
21:15:00 <ttx> #topic Oslo update improvements (dhellmann)
21:15:06 <ttx> dhellmann: damn, you again
21:15:11 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/024176.html
21:15:17 <dhellmann> yes, I've gone months without raising any issues at all :-)
21:15:30 <dhellmann> this one is about making update.py really smart, or just getting on with the business of making libraries
21:15:45 <hub_cap> ttx heh
21:16:01 <dhellmann> basically, figuring out the right hash starting point for an update.py that knows how to provide nice detailed log messages is super hard, and I'd just rather do the work to make libs
21:16:19 <dhellmann> BUT that means we need everyone to be patient with merges coming from oslo having maybe not the level of detail they would like for a little while longer
21:16:35 <dhellmann> what sort of compromise can we strike?
21:16:58 <russellb> what requires merges without detail?
21:17:11 <ttx> dhellmann: Do you think there will be less and less things in oslo-incubator ? Or more and more ?
21:17:16 <dhellmann> russellb: well, we may not have every hash of every commit listed in the message as it goes into nova, for example
21:17:27 <dhellmann> ttx: I would like to reduce its size, and keep it small
21:17:46 <jd__> git submodule anyone ? :)
21:17:47 <ttx> are we getting better at not copying code around ?
21:18:00 <ttx> jd__: out
21:18:11 * jd__ had to try
21:18:20 <dhellmann> ttx: I get lots of queries about adding things to the incubator, but I'm not watching what goes on between projects behind closed doors, as it were
21:18:50 <ttx> dhellmann: there is some value in improving update.py if it will be around forever
21:18:52 <jd__> I think having the top commit is enough, doing more is going to be a waste of time
21:18:53 <markmc> dhellmann, I still think adding the git has of the incubator commit to each file doesn't seem too hard
21:19:00 <markmc> dhellmann, but I haven't hacked it up either :)
21:19:09 <ttx> but then I haven't felt that much pain with the current update.py either
21:19:14 <dhellmann> markmc: updating the hash is not hard, it's figuring out the initial value
21:19:32 <dhellmann> markmc: and dealing with merges that only copy some of the modules, essentially skipping commits
21:19:47 <markmc> dhellmann, that's why I say each file - not openstack-common.conf
21:19:50 <russellb> just knowing what we're updating to seems valuable?  "update the following modules to commit foo"
21:19:53 <dhellmann> this may actually be an argument for mordred's idea of splitting the incubator up
21:20:02 <mordred> woot!
21:20:04 * mordred reads
21:20:10 <dhellmann> russellb: that part we could probably do
21:20:20 <dhellmann> markmc: yeah, come back with code :-)
21:20:27 <markmc> dhellmann, fair :)
21:20:29 * mordred supports
21:20:40 <dhellmann> markmc: we should discuss details offline
21:21:07 <markmc> dhellmann, I'm pretty easy, honestly - if we did syncs more regularly then syncing everything wouldn't be such a big deal
21:21:30 <dhellmann> I was hoping for some level of agreement that we'd be OK with good attempts, would take merges from oslo into other projects more often to stay in sync
21:22:14 <dhellmann> markmc: yeah, I'm worried about the "I'm syncing this one module" patches I saw when I looked at open reviews
21:22:14 <russellb> i'm fine with taking merges ... i don't think a decent commit message is much to ask for either
21:22:38 <russellb> at least just list the head you're syncing to if nothing else ...
21:22:51 <dhellmann> russellb: ok, that would be easy to do and not involve any tool changes
21:22:57 <dhellmann> we can totally do that
21:23:03 <markmc> dhellmann, actually, bleh - one-at-a-time syncs are pretty important when there are API changes
21:23:18 <markmc> dhellmann, you want the person familiar with the API change (ideally) to port the code
21:23:36 <dhellmann> markmc: sure
21:23:59 <dhellmann> the problem isn't doing those copies, or doing the bulk merges, it's doing both and trying to auto-generate sensible log messages for each
21:24:01 <dhellmann> or either
21:24:21 <dhellmann> anyway, I think russellb's proposal is good, and if someone has ideas for better tooling we can talk about it after the meeting
21:24:32 <ttx> sounds good
21:24:47 <ttx> next topic ?
21:25:09 <ttx> #topic Gate stability: top targets (russellb)
21:25:18 <russellb> ok, this has come up the last few meetings
21:25:27 <russellb> so i figured i'd take a turn putting it on the agenda, heh
21:25:34 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/024052.html
21:25:45 <russellb> a few of us took a deep dive into failures last week
21:26:01 <russellb> the vast majority of failures were simply due to load put on the deployment being too high
21:26:08 <russellb> so ... yeah.
21:26:13 <russellb> that email goes into a lot more detail
21:26:25 <russellb> short term: turn down the load
21:26:30 <russellb> long term: improve performance
21:26:36 <ttx> fwiw the current status is more due to the outage we had during the night / europe morning that built a backlog, things were running rather smoothly before that
21:26:38 <russellb> and things should be *much* better
21:26:56 <russellb> we've already started landing multiple patches related to improving nova performance
21:27:14 <russellb> with more already up for review and in progress
21:27:38 <russellb> the change that's going to make the biggest impact short term is: https://review.openstack.org/#/c/66379/
21:27:44 <russellb> change that isn't merged yet that is
21:28:02 <russellb> that's the wrong one ... i meant https://review.openstack.org/#/c/65805/
21:28:11 <russellb> so anyway, just wanted to share some status on that.
21:28:21 <ttx> fungi: did we get to the bottom cause on this morning's issue ? Some cloud provider fail ?
21:28:44 <ttx> those cloud things can't be relied on
21:28:48 <fungi> ttx: bug 1269001
21:28:50 <uvirtbot> Launchpad bug 1269001 in nodepool "Nodepool stops building any new nodes when one provider is down" [High,Triaged] https://launchpad.net/bugs/1269001
21:28:51 <markmc> russellb, very nicely done
21:29:16 <ttx> russellb: yep, that really made a difference already
21:29:20 <russellb> markmc: thanks
21:29:28 <fungi> ttx: it was unexpected outcome from the tripleo pioc cloud going down to be replaced by the production cloud
21:29:35 <fungi> s/pioc/poc/
21:29:49 <ttx> we should have some "I saved the gate" T-shirts to send to people
21:30:27 <markmc> fungi, wow, fun :)
21:30:34 <fungi> ttx: i want an "i broke the gate" tee shirt
21:31:04 <russellb> we'd have to print a whole lot of "i broke the gate" shirts
21:31:26 <fungi> bulk discount
21:31:28 <ttx> send them to some of our upstreams to, as a community relation exercise
21:31:32 <russellb> nice
21:31:34 <hub_cap> i vote gate assassin
21:31:44 <dolphm> how about "i fought the gate, and the gate won"
21:32:05 <ttx> ok, I think all that means, next topic
21:32:06 * dhellmann is sensing a theme building for the summit t-shirt for juno
21:32:28 <russellb> RIP Jeckyll
21:32:38 <ttx> <<Would you like a "I broke the gate" "I fought the gate" or "I fixed the gate" T-shirt ?>>
21:32:52 <ttx> #topic Red Flag District / Blocked blueprints
21:33:03 * markmcclain2 still wants to actually find/drive through juno, ga
21:33:10 <ttx> I want a "Jekyll was murdered" T-shirt
21:33:20 <ttx> We have two blocked blueprints to discuss
21:33:28 <ttx> https://blueprints.launchpad.net/heat/+spec/keystone-v3-only
21:33:32 <ttx> blocked on keystone review: https://review.openstack.org/#/c/66447/
21:33:37 <ttx> stevebaker, dolphm ?
21:34:06 <stevebaker> the review has only just been posted, so blocked may be overstating it
21:34:17 <ttx> let's say.. attention needed
21:34:22 <dolphm> on the keystone side, there's a sequence of three patches that was just proposed yesterday -- skimming through the commit messages, i don't expect them to take too long to land
21:35:03 <ttx> dolphm: ok, just prio them up as they are blocking more than just you :)
21:35:07 <dolphm> ++
21:35:18 <ttx> https://blueprints.launchpad.net/keystone/+spec/user-locale-api
21:35:23 <ttx> blocked on oslo reviews: https://review.openstack.org/#/q/topic:bp/i18n-messages,n,z
21:35:30 <ttx> dhellmann, dolphm ?
21:35:42 <dolphm> i don't think we're blocked anymore!
21:35:45 <ttx> one of those having a -2
21:35:52 <ttx> dolphm: damn
21:35:55 <dolphm> there's an outstanding patch on the oslo bp, but it doesn't look critical to keystone, so i think we can proceed
21:35:56 <dhellmann> the -2 is the config option we just discussed
21:36:08 <ttx> cool, plenty of time to discuss incubated projects i-2
21:36:13 <dhellmann> and the other item shouldn't be a blocker downstream except when that one locale is used
21:36:23 <ttx> dolphm: awesome
21:36:43 <ttx> dhellmann: sorry about that
21:36:47 <ttx> Any other blocked work that this meeting could help unblock ?
21:36:57 <dhellmann> ttx: np, dolphm and I discussed it earlier
21:37:33 <dolphm> dhellmann: i should have mentioned it to ttx ahead of this meeting :-/
21:37:58 <ttx> I guess everything is smooth and on track then
21:37:59 <ttx> #topic Incubated projects
21:38:11 <ttx> yay, plenty of time to look after our incubated friends
21:38:21 <ttx> SergeyLukjanov, devananda: still around ?
21:38:36 <ttx> kgriffs: what about you
21:38:43 <SergeyLukjanov> yup, I'm here
21:39:00 <ttx> https://launchpad.net/savanna/+milestone/icehouse-2
21:39:06 <flaper87> o/ for marconi (in cases kgriffs doesn't show up)
21:39:40 <ttx> SergeyLukjanov: 4 open blueprints, looks like you can complete them in time for i2
21:40:00 <ttx> SergeyLukjanov: the bug list could use some more assignees
21:40:02 <SergeyLukjanov> ttx, everything looks ok IMO, I'm going to release new version of client that block one of them
21:40:24 <SergeyLukjanov> ttx, yup, bug list looks kind overloaded atm
21:40:26 <kgriffs> o/
21:40:38 <ttx> SergeyLukjanov: just refine it as you get closer to the milestone
21:40:52 <ttx> only adding bugs with some assignee is generally a good idea
21:41:02 <SergeyLukjanov> ttx, I'm planning to make bug fix day to make a cleanup of confirmed/triaged bugs
21:41:05 <ttx> otherwise looks good
21:41:23 <ttx> ok, quick look at Marconi
21:41:24 <SergeyLukjanov> ttx, most of the open bugs are <= medium
21:41:44 <ttx> kgriffs, flaper87: we didn't have time to discuss incubation status at the TC meeting, so it will be next week
21:41:50 <kgriffs> oic
21:41:56 <flaper87> ttx: kk
21:42:01 <ttx> (was the hour before)
21:42:06 <ttx> https://launchpad.net/marconi/+milestone/icehouse-2
21:42:22 <ttx> plan looks good and in good shape
21:42:34 <ttx> are we still planning to publish a tarball for i-2 ?
21:42:40 <kgriffs> yes
21:42:43 <flaper87> yes
21:42:53 <kgriffs> so, mostly we have bugs to finish up over the next 7 days
21:42:54 <ttx> ok. So the branch is generally cut at the end of the Tuesday
21:43:03 <ttx> then you can still ahve a few bugfixes in
21:43:08 <ttx> (proposed as backports)
21:43:12 <kgriffs> makes sense
21:43:22 <ttx> but most things should be baked by Tuesday evening
21:43:36 <flaper87> cool, sounds good
21:43:47 <ttx> backports are generally for show stoppers you detect in the proposed build
21:44:15 <ttx> your page looks good, congrats
21:44:27 <ttx> NobodyCam: around?
21:44:34 <flaper87> ttx: thanks
21:44:35 <NobodyCam> si
21:44:48 <NobodyCam> devananda: should also
21:44:50 <devananda> ttx: yep, here
21:44:56 <ttx> devananda: oh hi
21:45:01 <ttx> https://launchpad.net/ironic/+milestone/icehouse-2
21:45:07 <ttx> looks in good shape too
21:45:12 <devananda> ack
21:45:20 <ttx> you might want to assign someone to bug 1195073
21:45:21 <uvirtbot> Launchpad bug 1195073 in nova "pxe deploy timeout defaults to unset" [Medium,Triaged] https://launchpad.net/bugs/1195073
21:45:26 <ttx> if you want it fixed by next week
21:45:33 <devananda> will do
21:45:40 <devananda> we have a lot of bug fixes in flight at the moment
21:45:46 <devananda> trying to iron out issues with deploy()
21:46:00 <devananda> i may fast-track them to try to get things working this week
21:46:11 <ttx> ok, looks like you're all in good shape
21:46:11 <devananda> and then add unit tests / cleanup just after that
21:46:27 <ttx> any question on the milestone publication process ?
21:46:34 <ttx> or on anything else ?
21:46:56 <NobodyCam> not from /me.
21:47:08 <devananda> nope. I'll be back in the states this week and around to do all the things for milestone next week
21:47:43 <ttx> ok then
21:47:48 <ttx> #topic Open discussion
21:47:58 <ttx> Anything else, anyone ?
21:48:11 <ttx> Or can we all have 12 minutes of our lives back
21:48:30 <SergeyLukjanov> nothing from my side
21:48:37 <russellb> yay OpenStack
21:49:03 <ttx> alrighty then
21:49:04 <ttx> #endmeeting