21:02:34 <ttx> #startmeeting project
21:02:35 <openstack> Meeting started Tue Jan  7 21:02:34 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:38 <david-lyle> o/
21:02:38 <openstack> The meeting name has been set to 'project'
21:02:40 <stevebaker> ttx: I did, new irc client - still configuring alerts
21:02:54 <ttx> stevebaker: we can do it just after this one
21:02:57 <stevebaker> ok
21:02:59 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:03:08 <ttx> #topic Icehouse-2
21:03:16 <ttx> We looked into icehouse-2 progress during the 1:1s today
21:03:31 <ttx> only two weeks left before icehouse-2. how time flies
21:03:39 <ttx> We are a bit late overall and I fear congestion at the gate next week
21:03:46 <ttx> So land what you can this week :)
21:03:51 <ttx> (if you can, eh)
21:03:54 <russellb> dang holidays
21:04:02 <ttx> We'll probably defer anything "not started" next Tuesday.
21:04:24 <ttx> in other news, we ahve a few topics up for discussion
21:04:31 <ttx> #topic Nova-network deprecation status
21:04:37 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/023555.html
21:04:52 <ttx> We said we'd make a final call after icehouse-2, but now is a good time to take the pulse on this
21:05:10 <ttx> markmcclain, russellb: what's the status at this point ?
21:05:30 <russellb> sdague: and if you're around, QA perspective would be good too
21:05:44 <markmcclain> we're actively working on closing the gaps from both a feature and QA side
21:06:14 <markmcclain> we're meeting next week to sprint on Neutron/Tempest
21:06:22 <russellb> think they'll be closed by icehouse-2?  or still a ways off?
21:06:39 <sdague> it still feels a bit off from there to me
21:07:00 <ttx> there is also a general perception that built over time that make people oversensitive to the issue
21:07:12 <sdague> my experience is it's at least 4 - 6 weeks to stabalize the parallel jobs, and those aren't lit yet
21:07:24 <ttx> Ideally feature parity would let us keep nova-network frozen
21:07:39 <markmcclain> yeah stabilizing the jobs has uncovered other issues
21:07:44 <ttx> then we can wait for more confidence before marking deprecated
21:07:47 <sdague> I don't know where we stand on the feature matches, that's just the qa side
21:08:02 <markmcclain> which has been a good thing, but has slowed velocity down
21:08:08 <russellb> markmcclain: how about the feature parity bits?
21:08:14 <russellb> there really wasn't too much left there
21:08:17 <russellb> one big thing, really
21:08:23 <markmcclain> multi-host?
21:08:24 <markwash> o/
21:08:25 <russellb> yeah
21:08:42 <markmcclain> so still have two different groups working on it
21:08:45 <jog0> what about having a good open source default that scales moderately well
21:09:13 <ttx> jog0: do we ahve that in the nova-network case ?
21:09:26 <markmcclain> they're working from different positions that have different payoffs (ie one gets us a good solution short term and the other pays off long term)
21:09:32 <ttx> ("moderately scalable")
21:09:35 <jog0> ttx: AFIK yes
21:09:41 <russellb> jog0: yeah i guess that was the other thing
21:09:54 <sdague> so salv-orlando said a bunch of the issues are ovs 1.3
21:10:07 <sdague> when moving to ovs 2.0 a lot of issues fixed themselves
21:10:11 <russellb> i was actually just talking to a user yesterday saying that they were trying neutron with OVS on 200 nodes and it fell over badly
21:10:15 <russellb> nova-network was/is fine
21:10:17 <russellb> with havana
21:10:27 <markmcclain> as part of the parallel testing we've been uncovering and fixing some of scaling issues
21:10:34 <russellb> that's good
21:10:39 <jog0> russellb: thats a a great benchmark to try to match here
21:10:46 <markmcclain> OVS 2.0 is the direction to head long term
21:10:47 <russellb> so maybe icehouse will fair better
21:10:51 <sdague> russellb: any idea what ovs version?
21:10:52 <markmcclain> but will require some distro support
21:10:57 <russellb> sdague: nope, but i can find out
21:11:06 <russellb> whatever we have in RHEL i suspect
21:11:07 <sdague> russellb: that would be helpful, just to get more data
21:11:21 <russellb> and i should know the answer to that ...
21:11:28 <ttx> russellb: there are two pieces I think... you need feature parity to keep nova-network frozen. you need performance parity / stability partity before marking it deprecated
21:11:30 <sdague> I agree, we should have a scaling threshold
21:11:35 <markmcclain> russellb: would love to know how their cluster fell over
21:11:43 <russellb> ttx: working on getting more info
21:11:47 <russellb> err, markmcclain ^^
21:12:09 <russellb> will point you to info once i have it
21:12:15 <markmcclain> ttx: so feature parity is being worked through testing
21:12:45 <ttx> russellb: I think we may get to feature parity, but fear that perf/stability parity might be farther away, not even talking about the confidence to build around it
21:12:49 <russellb> ttx: the problem is that we've had a *much* longer time between freeze and deprecation than is healthy
21:12:51 <ttx> (in icehouse)
21:13:03 <markmcclain> performance parity depends on what you're measuring
21:13:09 <sdague> I do think all of this paints a story that isn't going to close in icehouse
21:13:22 <russellb> so ... i'm tempted to unfreeze, and revisit a freeze (and deprecation) when we have a much better feel for when that will happen
21:13:31 <sdague> I think some huge strides have been made, which have been great
21:13:42 <russellb> sdague: that's what i'm afraid of
21:13:50 <markmcclain> unfreezing is bad idea because it creates a moving target
21:13:52 <ttx> yes, great progress and velocity, the track is just longer than expected
21:13:55 <sdague> but I don't think we're going to close on all of it in icehouse, not in a way I'd feel comfortable with
21:13:56 <jog0> markmcclain: and the migration story (re: a doc saying if useing nova-network use this in neutron )
21:14:05 <dhellmann> markmcclain: +1
21:14:33 <ttx> russellb: how much would unfreezing really create a moving target ? what would make it in, really ?
21:14:42 <russellb> i don't expect major work
21:14:44 <jgriffith> just curious are there signficant proposals out there for changes to nova-net?
21:14:45 <markmcclain> jog0: we can get those docs written
21:14:46 <ttx> bugfixes, new features ?
21:15:00 <russellb> but there are all kinds of things we haven't bothered doing because it was on it's way out
21:15:06 <markmcclain> my question is that if folks want to change nova-net are they contributing to neutron?
21:15:17 <markmcclain> if not then we're fragmenting the devs
21:15:19 <russellb> no-db-compute is one example
21:15:23 <russellb> and that was a couple releases ago
21:15:51 <sdague> yeh, and I don't think it's reasonable to ask nova-network folks to work on neutron if they can't deploy it at scale in their envs.
21:15:53 <russellb> more minor things
21:15:57 <russellb> keeping it up to date with the rest of nova
21:16:05 <russellb> lots of that kind of stuff we have passed on while it's frozen
21:16:06 <ttx> markmcclain: I think russell is more talking about nova infra changes that were applied everywhere but in nova-net, like no-db-compute
21:16:12 <sdague> honestly, I'd be +1 with the unfreeze, as I do think it's been frozen too long
21:16:13 <russellb> mostly, yes
21:16:23 <russellb> so maybe just a softer freeze
21:16:28 <markmcclain> sdague: but when they don't contribute we lose that information and the problem being solve because it is not shared
21:16:36 <russellb> like ... we don't really want *major* work on it, because that should be neutron
21:16:49 <russellb> but we'll let smaller enhancements, and other infrastructure work to keep it up to date with the rest of nova
21:16:59 <ttx> russellb: we could have a soft freeze (no new feature, just keep it up to date)
21:17:07 <russellb> no major new features anyway
21:17:14 <ttx> some of those would still count as "features" but would not widen the gap
21:17:20 <markmcclain> moving to no db type stuff makes sense
21:17:24 <jgriffith> russellb: but then what do "minor" enhancements buy you anyway?
21:17:27 <ttx> like 'adopt nova new object model'
21:17:47 <russellb> jgriffith: probably something we'd have to take case by case
21:17:53 <jgriffith> russellb: fair
21:17:56 <russellb> ttx: yes, that's been the biggest pain
21:18:06 <jgriffith> ttx: that's an example I'm not sure I fully understand
21:18:09 <russellb> rpc versioning stuff, no-db-compute stuff, nova objects stuff ... all avoided nova-network
21:18:13 <ttx> markmcclain: so we could have a freeze for any feature that would widen the gap
21:18:17 <russellb> has gone for a few releases now
21:18:23 <russellb> and it's adding up
21:18:25 <ttx> but not a strict code freeze
21:18:34 <SlickNik> +1 on ttx / russelb's idea of a 'soft' freeze.
21:19:02 <markmcclain> a freeze on features makes sense will allowing framework changes to made
21:19:08 <ttx> markmcclain: if you get to feature parity, then we can easily argue that feature dev should happen in neutron
21:19:14 <russellb> performance enhancements would be OK i think
21:19:25 <russellb> someone told me they had some of those they hadn't submitted because they thought they would be rejected
21:19:27 <russellb> probably right
21:19:46 <markmcclain> performance enhancements should be ok as long as the information is shared with Neutron team
21:19:46 <ttx> it's just that nova-net users might not be ready to switch in icehouse, and need a working nova-net
21:19:47 <sdague> so I think this just needs to be more incentive for the neutron team to close the basic gaps.
21:20:06 <markmcclain> we might have already solved some of the same issues
21:20:16 * russellb nods
21:20:33 <russellb> of course, the other big problem with all of this is our messaging to the community at large
21:20:40 <russellb> i think it's pretty ... cloudy right now
21:20:46 <ttx> ok, we can revisit the state after your neutron sprint ?
21:20:57 <ttx> but I think this half-freeze has potential
21:21:18 <markmcclain> yeah I think we'll have a better idea where we stand after the 17th
21:21:27 <russellb> sounds good
21:21:59 <ttx> all that said, I'm very pleased with the focus on those issues in the neutron team
21:22:14 <ttx> it's just that the gap was deep
21:22:50 <ttx> and covering it can take longer than expected
21:22:57 <ttx> which brings us to the next topic
21:23:02 <ttx> #topic Gate stability (jgriffith)
21:23:28 <jgriffith> So going into next week I'm a bit concerned
21:23:36 <ttx> jgriffith: anything on your mind ? the 78-deep gate queue ?
21:23:45 <jgriffith> ttx: that would be correct
21:24:03 <jgriffith> I'm wondering if we need to rethink som things
21:24:13 <jgriffith> we don't seem to be solving the problem
21:24:13 <ttx> mordred, fungi, jeblair, clarkb: around?
21:24:23 <jgriffith> Or am I the only one that thinks there's a problem?
21:24:23 <sdague> jeblair and clarkb are in .au
21:24:44 <ttx> sdague: mordred is too
21:24:50 <russellb> well today there was a n ova problem that put us way behind
21:24:56 <jgriffith> sounds like maybe I'm in the minority
21:24:56 <ttx> or is he no
21:24:57 <russellb> libvirt package was updated by accident
21:24:57 <ttx> t
21:25:00 <sdague> jgriffith: definitely a problem. Still very few people working on race bugs
21:25:08 <russellb> and that caused all nova patches to fail until it was resolved
21:25:12 <sdague> and we had compounding issues
21:25:18 <mordred> ttx: sup?
21:25:21 <russellb> also for reference ... http://not.mn/gate_status.html
21:25:35 <jgriffith> russellb: yeah... make sense but I guess my quesiton is we continue to uncover more of these "races" than we fix
21:25:43 <russellb> but that was just today
21:25:46 <ttx> mordred: weekly "do we need to rethink some things about the gate" topic
21:25:50 <jgriffith> I'm beginning to wonder if our testing approach might need some tweaking?
21:25:57 <mordred> ttx: yeah.
21:25:59 * jgriffith ducsk while everybody throws things at him
21:26:00 <russellb> jgriffith: have any tweaks in mind?
21:26:10 <markmcclain> jgriffith: I also think that we keep finding races because we're adding better tests
21:26:19 <russellb> i generally always end up back at "we just need to fix the problems" ...
21:26:22 <jgriffith> russellb: So I just started thinking about this yesterday
21:26:29 <sdague> jgriffith: at lot of these races have been here a long time
21:26:32 <mordred> jgriffith: well - I think the problem is that what needs tweaking is what people hack on and how - but we've been using hte gate as a stick to try to force people to do so
21:26:34 <sdague> just no one is working on them
21:26:44 <jd__> russellb: +1 :)
21:26:48 <jgriffith> Ok
21:26:53 <jgriffith> Maybe I'm completely off base here then
21:26:57 <mordred> jgriffith: I agree we may need to think of new things - but not tech things in the gate- I think we may not be motivating people successfully
21:27:01 <fungi> ttx: yeah, here
21:27:04 <jgriffith> I don't agree that it's "nobody working on them though"
21:27:09 <russellb> i think the motivation issue is key
21:27:19 * jog0 thinks of beer
21:27:29 <russellb> most nova gate bugs are collecting dust i think
21:27:30 <ttx> one bug, one beer
21:27:40 <jgriffith> I think there's a number of things going on that are not helping
21:27:56 <jgriffith> workign on the issues may be part of it
21:28:02 <ttx> sdague: any specific project to shame ?
21:28:02 <jgriffith> but there are a TON of distractions
21:28:15 <jgriffith> gitignore, vim heading, __init__ files, typos in comments
21:28:27 <jgriffith> and my favorite the 10 part commits (one line each)
21:28:38 <jgriffith> This adds stress to the review queues, the gates etc etc
21:28:43 <dhellmann> jog0: maybe you're onto something -- a special party at the summit for contributors to the race issues?
21:28:46 <sdague> ttx: not really, I'm still working towards better dashboard, but I get dragged down until actually trying to debug the key issues as well
21:28:47 <jgriffith> and takes attention/focus away from those races in the gates
21:29:21 <jgriffith> and trying to determine better ways of exposing those races early/first time around
21:29:33 <jog0> so http://status.openstack.org/elastic-recheck/ lists about 20 bugs or so that are actively happening in the gate
21:29:34 <ttx> I think we are at a key moment -- adding better tests so catching more bugs, with the tooling and reporting slightly behind and people not all lined up to fix them
21:30:00 <ttx> trick is overall, that means stuff is getting better
21:30:10 <jgriffith> ttx: I fully agree with that
21:30:19 <ttx> yes, it hurts our velocity
21:30:32 <jgriffith> and I apologize that I'm not bringing this up with a proposal other than maybe rethink some things
21:30:34 <jog0> jgriffith: as for distractions, I think you just need to -2 more
21:30:42 <ttx> but then, maybe we shoudln't be that much fast as long as we have those bugs around
21:30:44 <jgriffith> jog0: sure
21:30:55 <jgriffith> ok
21:30:55 <sdague> I also think that given the review load, I think it's totally ok to start -2ing things at this point that aren't useful
21:30:59 <sdague> it's i2 almost
21:31:09 <russellb> hurting the velocity is probably good if our quality is hurting
21:31:11 <sdague> and so time to start shedding review load
21:31:12 <jd__> "You frustration I hear", said ttx, "but on the right path we are."
21:31:14 <ttx> the tension comes when the bugs are on one project and the delays hit other projects (see the discussion from last meeting)
21:31:20 <russellb> velocity is only useful if the quality stays high
21:31:21 <jgriffith> Well it seems I'm in the minority on some of this so we can move on
21:31:25 <jog0> jgriffith: here was one i just did https://review.openstack.org/#/c/64393/
21:31:30 <dolphm> russellb: ++
21:31:36 <ttx> jd__: summarizing, you are good at.
21:31:53 <sdague> jgriffith: I think you are not in the minority in believing the current situation sucks
21:32:06 <notmyname> jgriffith: I agree with your concern
21:32:07 <jgriffith> sdague: to be clear, I'm not hear to say "this sucks"
21:32:09 <russellb> ttx: totally get the cross project tensions  ... not sure what to do about that
21:32:13 * notmyname just woke up at 5am in AUS
21:32:20 <jgriffith> I was hoping to get some thought on maybe doing something "differently"
21:32:46 <jgriffith> whehter that be changes in how we gate... changes in philosophy on commits during certain periods of time etc
21:32:57 <sdague> jgriffith: yeh, so to me differently is having any gate bug go a week without an update
21:33:01 <jgriffith> and of course getting discovered issues worked on
21:33:07 <jog0> jgriffith:  when there are critical gate bugs, I think its very reasonable to ignore all other reviews and work on the gate / other ciritcal bug
21:33:10 <sdague> https://bugs.launchpad.net/nova/+bug/1257626 - last updated a month ago
21:33:11 <ttx> jgriffith: there is some potential around slarter gate queues, as notmyname proposed last meeting
21:33:15 <ttx> smarter*
21:33:17 <sdague> it's like #4 on the list
21:33:21 <jgriffith> sdague: agree, and yet we have bugs with 500+ rechecks from August
21:33:27 <ttx> which needs some dev help to happen
21:33:39 <sdague> jgriffith: right, that was my point on "*no one* is working on them"
21:33:49 <sdague> which really should have been: not enough people are working on them
21:33:51 <russellb> it seems like more people fixing these bugs is the biggest issue by far
21:33:52 <jgriffith> sdague: fair enough
21:34:04 <russellb> and people want to work on the fun stuff (features etc)
21:34:08 <jog0> russellb: agreed
21:34:16 <jgriffith> alright... so that's all fair
21:34:17 <ttx> things are tolerable until we get hit by some external issue and then the day is lost
21:34:33 <jgriffith> its going to hit the fan next week :)
21:34:36 <ttx> so it's a bit of a fragile equilibrium
21:34:45 <sdague> ttx: honestly, I'm not convinced we're at tolerable
21:34:52 <sdague> even without external events
21:34:53 <jgriffith> maybe when that happens people will be more interested
21:35:01 <jgriffith> as in their stuff isn't landing
21:35:04 <sdague> but the pain threshold hasn't seemed to bother enough people to dive in
21:35:11 <sdague> I htink the queue is 22hrs deep right now
21:35:14 <jgriffith> sdague: ttx I'd say we are not
21:35:16 <jgriffith> by a long shot
21:35:16 <ttx> sdague: might be a european perspective. At least we have the option of sneaking our patches before the queue fails
21:35:24 <jgriffith> ttx: LOL
21:35:34 <jog0> ttx: with a 22 hour queue you don't
21:35:42 <sdague> ttx: yeh, not at the moment you don't
21:36:12 <jgriffith> Ok, that's all I have I guess.  I'll think on how to motivate more effort on bug fixes
21:36:13 <ttx> sdague: about current situation, is it just backlog, or some persisting issue ?
21:36:32 <jeblair> o/
21:36:32 <jgriffith> and I would ideally love to come up with a solution to expose things first time around
21:36:34 <sdague> ttx: so there were a few compounding events, like the libvirt upgrade
21:36:47 <sdague> jgriffith: so math is actually against us on that one
21:36:51 <jog0> https://bugs.launchpad.net/tempest/+bug/1253896 is my favorite bug
21:37:02 <david-lyle> bounty system? don't know who provides the prize though
21:37:03 <sdague> ttx: and now zuul is so hammered, it's actually also timing out bugs
21:37:05 <jgriffith> sdague: and you can't beat math as I've always said in the past
21:37:11 <jog0> filed and critical since second half of november
21:37:14 <notmyname> jgriffith: I'd be happy to work with you figure something out
21:37:32 <jgriffith> notmyname: thx
21:37:48 <markwash> kidnapping first born, anyone?
21:37:49 <markmcclain> jog0: https://bugs.launchpad.net/tempest/+bug/1253896 has actually been seeing active work
21:38:02 <jgriffith> notmyname: There's a lot of really sharp people already thinking/working on it
21:38:04 <ttx> I'd suggest cloning salvatore orlando a few thousand times
21:38:23 <jgriffith> It'd be interesting if we all got together on something other than "get more people working on it"
21:38:28 <markmcclain> ttx: +1
21:38:42 <markwash> that was a test. good news. you passed
21:39:15 <sdague> jgriffith: maybe. I'm not sure we're going to clever our way out of fixing bugs though :)
21:39:33 <jgriffith> sdague: I'm personally a firm believer in smarter rather than harder :)
21:39:39 <jog0> jgriffith: so right now all we have is the atomic gate is wedged stop +2ing tactic
21:39:45 <jog0> which is not a good one to use
21:40:06 <jgriffith> my point is how to NOT wedge the gate in the first place
21:40:08 <ttx> I think the concept of slowing down feature development until bugs are fixed is good. The problem is that the pain shared by everyone, but not everyone can fix those bugs where they are
21:40:14 <jgriffith> and I don't buy the "fix the bugs"
21:40:38 <jgriffith> because there's something wrong IMO with either our code, or how we're testing
21:40:38 <ttx> hence the frustration
21:40:51 <jog0> jgriffith: so your concerend so many bugs are getting into the gate?
21:40:54 <sdague> jgriffith: put all of openstack into 1 single threaded process
21:41:03 * jgriffith proposes a quality / tech-debt release.. no new features :)
21:41:04 <sdague> the issue is really races between components
21:41:10 <jgriffith> jog0: exactly
21:41:26 <sdague> which means there are timing challenges, which is why they show up 1 or 2% of the time
21:41:28 <jgriffith> sdague: if that's true we need to look at what we're doing as a whole
21:41:38 <jgriffith> ie the design/arch of OpenStack
21:41:40 <markwash> I guess I feel like if someone contributed a test that failed to glance, I wouldn't even look at it, because it would make my unit test suite unusable, even if the test reflected an actual bug. . so I'm not sure how nondeterministic failures are really different
21:41:42 <jog0> the odds are against us
21:41:44 <jgriffith> but I don't necessarily know if I agree
21:41:59 <jgriffith> there are things that are done in tests that aren't really valid sometimes IMO
21:42:06 <ttx> ok, we need to move on
21:42:13 <ttx> no magic bullet again
21:43:02 <jgriffith> k.. thanks everyone
21:43:04 <ttx> although I've hope that the current efforts already in progress will improve the situation
21:43:30 <ttx> (new elastic-recheck reporting, smarter queues, moar neutron parallel testing)
21:43:35 <ttx> next topic
21:43:53 <ttx> #topic Brick library (jgriffith)
21:43:57 <ttx> jgriffith: you again
21:44:08 <jgriffith> oi
21:44:13 <ttx> you're on fire
21:44:17 <russellb> gogogo
21:44:17 <jgriffith> Ok... so I've talked with some folks on this
21:44:32 <jgriffith> Cinder came up with this idea of brick.. basicly mini-cinder service
21:44:51 <jgriffith> do things like manage LVM/local storage on compute nodes
21:45:03 <jgriffith> long term goal is things like scheduling local disk on instance nodes
21:45:20 <jgriffith> also things like manilla, trove etc
21:45:34 <jgriffith> IMO should leverage cinder for block storage rather than write their own
21:45:58 <jgriffith> My proposal is to skip incubation in oslo and create a lib right out of the gate
21:46:02 <jgriffith> it would fall under Cinder
21:46:21 <jgriffith> then once that's set up of course go through and pull into the other projects
21:46:46 <jgriffith> I've chatted with a couple of folks and wanted to get all the PTL's up to speed
21:46:48 <russellb> i don't think we really incubate any other library right?  incubating libs in oslo was just while the API was unstable
21:46:50 <ttx> jgriffith: is it a library ?
21:46:50 <jd__> sounds sane
21:46:51 <jgriffith> make sure there are no objections
21:47:00 <russellb> seems fine to me
21:47:04 <jgriffith> ttx: it's not yet, I need to turn it in to one :)
21:47:13 <jd__> not sure about the oslo part, but dhellmann might have an opinion
21:47:19 <jgriffith> I'll need help from ttx and the infra gurus on that front :)
21:47:23 <ttx> no need for incubation in the oslo sense
21:47:30 <jgriffith> jd__: I spoke with dhellmann on this, skip oslo
21:47:38 <russellb> and no need for incubation in the normal sense either right?
21:47:39 <jgriffith> ^^ skip oslo was what we came up with
21:47:46 <jgriffith> russellb: that's what I'm hoping
21:47:47 <dhellmann> yeah, we discussed this and I agree it doesn't make sense for this to go through the oslo-incubator
21:47:49 <russellb> works for me
21:47:53 <jd__> jgriffith: ok, so that would be just a standard Python library?
21:47:57 <jgriffith> russellb: I'm hoping it's use in cinder has been the "incubatio"
21:48:00 <ttx> jgriffith: one question left was the use of the openstack namespace for the lib name, right
21:48:05 <sdague> jgriffith: this become oslo.foo or cinder.foo?
21:48:06 <jgriffith> ttx: yes
21:48:18 <jgriffith> sdague: that's the million dollar question :)
21:48:19 <jd__> please make a standard Python lib, don't zope it
21:48:26 <jgriffith> jd__: noted :)
21:48:30 <ttx> jd__: nice :)
21:48:34 <dhellmann> sdague: it can only be cinder.brick if cinder is converted to a namespace package (which isn't a bad idea, but will involve some code churn)
21:48:47 * jgriffith hates code churn
21:48:56 <russellb> just brick seems fine
21:48:57 <jgriffith> but if it's worth the end result I'm down for it
21:49:00 <russellb> if not already taken
21:49:12 <jgriffith> I'll deal with a name if needed
21:49:13 <sdague> ok, so the only thing to note is we'll need to gate it like the oslo.config and oslo.messaging libs
21:49:29 <jgriffith> sdague: that's the part I'm going to need some help on, at least some guidance
21:49:31 <sdague> as that's our current policy for things like that (which might get revisted)
21:49:35 <dhellmann> sure, normally that's what I'd say, but this is really only intended to be used by openstack apps so that's why we were discussing a global namespace
21:49:39 <jgriffith> sdague: roger that
21:49:55 <sdague> jgriffith: yeh the oslo graduation section lays most of it out
21:50:08 <ttx> is this really only intended to be used by openstack apps ?
21:50:11 <sdague> and ttx is going through it with oslo.rootwrap right now
21:50:17 <ttx> lots of fun
21:50:30 <ttx> vaguely documented on the oslo page now
21:50:42 <jgriffith> ttx: well I'm not desiging it with anybody else in mind but I don't have a problem if others pick it up use it
21:50:51 <jgriffith> but I don't want to maintain it in that perspective
21:51:03 <jgriffith> Life is much simpler when it's "openstack only" IMO
21:51:35 <jgriffith> anyway, I just wanted to run this by the other projects
21:51:42 <jgriffith> mostly russellb (so thanks russellb )
21:51:51 <ttx> jgriffith: do you need anything more on that subject, or can we move on ?
21:51:54 <jgriffith> make sure there's now "WTH is this"
21:52:03 <jgriffith> ttx: move on... thanks everyone
21:52:10 <russellb> jgriffith: sure!
21:52:16 <ttx> #topic Red Flag District / Blocked blueprints
21:52:24 <ttx> No blocked blueprint afaict
21:52:33 <ttx> Any blocked work that this meeting could help unblock ?
21:52:49 <ttx> 78-deep gate doesn't count.
21:53:46 <jog0> 76*
21:53:50 <ttx> yay
21:54:17 <sdague> so coming back to the gate issue, one thing we haven't tried is global gate bug fix days. Especially if you got a lot of PTLs and top tech folks to sign up for devoting a day it might shake some of these loose.
21:54:24 <sdague> elaphant gun approach
21:54:35 <russellb> sdague: i'd love to do that
21:54:52 <ttx> mondays are good moments for that. Clean gate
21:55:02 <stevebaker> sounds like a good idea
21:55:03 <russellb> it's not a long term sustainable approach ... but it's good for playing catchup
21:55:08 <russellb> and i think we need to play catchup right now
21:55:12 <ttx> +1
21:55:13 <jog0> ++
21:55:18 <SlickNik> +1
21:55:20 <russellb> i'd be happy to devote at least a full day, if not a couple
21:55:36 <ttx> sdague: go for it
21:55:50 <sdague> damn, I just signed myself up for organizing that didn't I....
21:55:50 <ttx> just track the results to see if it made a difference :)
21:56:01 <russellb> sdague: sure did
21:56:07 <russellb> ttx: good call
21:56:17 <ttx> #topic Incubated projects
21:56:23 <sdague> ok, well with montreal I'll plan to do one post i2
21:56:26 * NobodyCam is here for ironic
21:56:32 <ttx> 4 minutes for questions if any
21:56:52 * SergeyLukjanov here too
21:56:54 <ttx> NobodyCam: are we stil on track for an icehouse-2 functional milestone of ironic ?
21:57:32 <NobodyCam> Ironic update. we are looking mostly good. we may have a issue with neutron intragration, but have already started on a fall back plan for that case
21:57:34 <ttx> SergeyLukjanov: https://launchpad.net/savanna/+milestone/icehouse-2 looking good
21:58:18 <SergeyLukjanov> ttx, yup, heat integration is already landed
21:58:49 <ttx> fwiw we should have some incubation status intermediary meeting soon at the TC level
21:58:53 <ttx> will keep you posted
21:59:12 <NobodyCam> great
21:59:19 <ttx> #action ttx to organize intermediary incubation status TC meeting soon
21:59:34 <ttx> any question ?
21:59:53 <ttx> no time left for open discussion
22:00:25 <NobodyCam> Thank you all
22:00:28 <ttx> #endmeeting