14:00:57 <russellb> #startmeeting nova
14:00:58 <openstack> Meeting started Thu Mar  6 14:00:57 2014 UTC and is due to finish in 60 minutes.  The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:01 <openstack> The meeting name has been set to 'nova'
14:01:05 <russellb> o/
14:01:07 <mriedem> hi
14:01:12 <n0ano> o/
14:01:48 <russellb> #topic Icehouse
14:01:59 <russellb> feature freeze week!
14:02:04 <russellb> #link https://blueprints.launchpad.net/nova/+milestone/icehouse-3
14:02:06 <russellb> icehouse-3 is out
14:02:14 <russellb> 39 blueprints and 172 bugs
14:02:29 <russellb> focus now is on RC1
14:02:35 <russellb> #link https://blueprints.launchpad.net/nova/+milestone/icehouse-rc1
14:02:46 <russellb> there are 5 blueprints there.  those are the ones that have been given an exception so far
14:03:05 <russellb> there are a number of requests for FFEs on openstack-dev.  most of them are blocking on nova-core sponsors
14:03:17 <russellb> no point in approving an exception without reviewers ready to push the review to completion ASAP
14:03:43 <russellb> in case you missed it, there's a ML post about FFE process:
14:03:45 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/029021.html
14:04:03 <russellb> also relevant, ttx wrote a nice blog post about why we do feature freeze
14:04:05 <russellb> #link http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/
14:04:28 <mriedem> russellb: has that bug list been scrubbed?
14:04:32 <ttx> Tl;Dr: we do FF because we care
14:04:37 <russellb> ttx: :-)
14:04:45 <russellb> mriedem: i beleive it's the carry over from icehouse-3
14:04:51 <mriedem> yeah, that's what it looks like
14:05:06 <mriedem> e.g. https://bugs.launchpad.net/nova/+bug/1240043 doesn't seem high prioirty given the v3 diagnostics bp dropped out
14:05:18 <russellb> agreed
14:05:22 <johnthetubaguy> mriedem: +1
14:05:26 <mriedem> i'll update it
14:05:32 <russellb> we need to make the bug list our "blocking release of RC1" list ASAP
14:05:42 <mriedem> yeah, that's why i was looking
14:05:50 <russellb> anything that's "would be nice, but not worth blocking" should just be tagged with icehouse-rc-potential
14:06:09 <russellb> and from past experience, we have to be diligent about maintaining this list
14:06:13 <russellb> people will just target the whole world to it
14:06:18 <russellb> and it gets frustrating :-)
14:06:45 <garyk> has the meeting started?
14:06:52 <russellb> garyk: yes.
14:06:52 <mriedem> but my very driver specifc thing needs to be in icehouse!
14:07:00 <russellb> mriedem: critical priority?
14:07:06 <mriedem> joking
14:07:29 <russellb> So, that pretty much covers the overview of current status
14:07:40 <russellb> with that, i'm happy to use the rest of the time to talk about specific FFE requests, or bugs
14:07:55 <russellb> based on who's here and what you want to talk about
14:08:43 * russellb waits for any requests
14:09:11 <garyk> russellb: thanks for the work on the instance groups
14:09:17 <garyk> the api comments were  addressed
14:09:25 <garyk> the update method was removed.
14:09:31 <russellb> garyk: np ... they were? ok, i will review again asap then
14:09:36 <russellb> i was pretty concerned
14:09:36 <garyk> i am not sure if i like this one and was wodnering what you thought?
14:09:51 <russellb> which one?
14:09:52 <garyk> the fact that we support only one policy most probably makes sense
14:10:10 <johnthetubaguy> russellb: might be good to get feedback on the crazy scheme for Juno-1, but thats for the end of the meeting
14:10:31 <garyk> johnthetubaguy: is that your proposal for the bps?
14:10:37 <johnthetubaguy> yeah
14:10:39 <russellb> johnthetubaguy: yeah i replied on list
14:10:47 * johnthetubaguy reads email
14:10:56 <garyk> i dont think that it was crazy. just sensible and trying to unblock the bottleneck
14:11:05 <russellb> johnthetubaguy: basically +1, kind of, with caveats that we can't guarantee anything ... but in general i think you're encouraging best practice
14:11:38 <garyk> i think that we should adopt it for all milestones
14:11:47 <garyk> then will not be a crazy rush at the end.
14:12:03 <russellb> i think there's a crazy rush most of the time, and then just insanity at the end
14:12:15 <johnthetubaguy> russellb: yep, the extra caveats are importing, I am +1 those
14:12:15 <PhilD> :-)
14:12:20 <garyk> that is, we should make sure we focus on certain bps in each milestone. then we can split the load across the release cycle instead of the last 2 days
14:12:55 <johnthetubaguy> garyk: that is the plan, but often the code just isn't up for review before the last few weeks
14:13:40 <russellb> there be dragons as you approach feature freeze
14:14:04 <garyk> johnthetubaguy: i just think that if we indicated that if BP X had to be ready by milestone Y then it may solve the problem
14:14:21 <russellb> so, we had this cool plan for icehouse that incorporated that idea
14:14:42 <russellb> reviewers would sponsors BPs to commit to reviewing them, as long as it was ready for the cycle it was sponsored for
14:14:45 <russellb> if it was late, priority dropped
14:14:58 <russellb> and then, you know ... that totally fell apart because nobody sponsored anything :-)
14:15:34 <russellb> hard to figure out the best thing that works
14:15:39 <PhilD> Still feels to me that too often we are doing design reviews right up to the end of what should be implemenation reviews (i.e. BP gets approved, code goes through multiple review cycles (the first few of which settle the design issues) and then right at the end a new "approach" type issue is raised.   Anything we can do to break that pattern would be good
14:15:53 <russellb> +1
14:15:59 <johnthetubaguy> +1
14:16:09 <alaski> agreed.  o/ btw
14:16:11 <garyk> +1
14:16:14 <russellb> alaski: o/
14:16:17 <johnthetubaguy> up front blueprint designs are better now, but we need to evolve that
14:16:25 <alaski> For api bps, I think having a schema defined is a good start
14:16:54 <johnthetubaguy> now we use them for sure, I was OK with at least examples before, but thats probably a bit lax
14:17:07 <garyk> most of the time the bps are very sparse when it comes to implementation details
14:17:19 <PhilD> Like more rigor in the BP stage, recognising that design reviewres and code reviewers aren't necessarily the same skill set, some non coders probably have a really useful role at the design review stage
14:17:23 <garyk> i do not think that there is a bp that indicates a complete design from A - Z
14:17:38 <johnthetubaguy> so, in part they were blueprints that were approved a while ago, I plan to do a build un-approve soon...
14:17:42 <russellb> i think if we're hurting bad enough in review bandwidth, we absolutely *can* afford to be a lot more strict on the blueprint approval side
14:17:43 <garyk> if there was the review will be on the BP and not the code.
14:18:00 <russellb> filter out more of the stuff higher up in the  process, to ensure that when stuff makes it to code review it's closer
14:18:02 <PhilD> Well that's a problem in the BP - there should be a minimum set of detail required,   Sometimes seems that the BP just gets rasied as a reason for posting the code
14:18:11 <alaski> I don't think we can expect all blueprints to have a complete design
14:18:22 <russellb> alaski: indeed ... case by case
14:18:33 <alaski> what I typically look for is a clear scope, so it's clear when the blueprint can be considered done
14:18:39 <russellb> alaski: but we should at least be able to bless a direction, maybe we need a 2 stage blueprint review
14:18:53 <russellb> "yes we like the tasks concept, now come back for stage 2 review with an API design"
14:18:56 <johnthetubaguy> russellb: two stage?
14:18:57 <russellb> for example
14:19:01 <johnthetubaguy> ah got you
14:19:06 <alaski> russellb: makes sense
14:19:10 <johnthetubaguy> direction then detail I guess?
14:19:17 <russellb> yeah, perhaps
14:19:21 <russellb> just thinking out loud
14:19:27 <russellb> "out loud"
14:19:37 <alaski> heh
14:19:40 <russellb> not actually talking to myself :)
14:19:42 <PhilD> @alaski I know some concepts are easier to understand once the basic code is there, but that's not an excuse really for a -2 on a design issue after months of work / refinement
14:19:56 <russellb> PhilD: yep, that's a process failure i think
14:20:09 <russellb> not that we shouldn't -2 if it really is bad ... but ... we broke down if we let it make it that far
14:20:14 <johnthetubaguy> +1 that shows a bad blueprint review
14:20:43 <alaski> PhilD: agreed.  but the times I remember things like that happening is when the code creeps a bit beyond what the blueprint was understood to entail
14:20:44 <johnthetubaguy> one issue we have is tooling, thinking we might start using wiki pages so we can at least track history...
14:20:49 <sdague> so what if we used gerrit for detailed blueprint review instead of launchpad?
14:20:55 <sdague> like make a doc directory in Nova
14:21:01 <sdague> for proposed blueprints
14:21:09 <russellb> sdague: NEP, Nova Enhancement Proposal?  :)
14:21:18 <johnthetubaguy> sdague: hmm, that could work...
14:21:21 <garyk> maybe we should create a checklist for BP's. that is, we expect that the drafter of the BP fill in a certain template. then maybe we can encounter problematic issues before the review
14:21:23 <russellb> quite interesting idea ...
14:21:28 <PhilD> Right - if we really need to -2 code because it will break the system badly then we have to do that of course - but it still means we failed somewhere along the way and wasted a lot of someones effort
14:21:39 <johnthetubaguy> garyk: we have the review checklists already
14:21:41 <sdague> then we'd get the benefits of the review process, could link it from the blueprint
14:21:41 <russellb> garyk: we have that on the wiki ... https://wiki.openstack.org/wiki/Blueprints
14:21:44 <russellb> or that's the idea
14:22:09 <alaski> as long as NEP8 can be something about style/hacking checks
14:22:12 <russellb> hmmmm, so blueprints just a link to gerrit, and it's approved with the gerrit review is approved ...
14:22:14 <sdague> :)
14:22:23 <russellb> easier for people to participate
14:22:26 <alaski> but I am intrigued by the idea
14:22:26 <russellb> easier to track revisions
14:22:35 <dripton> I think Nova having a different BP process than the rest of OpenStack would be an extra hurdle for people working on multiple projects.  I don't see a ton of upside.
14:22:40 <sdague> russellb: yeh, I think all the details would still need to be figured out
14:22:42 <russellb> FWIW, we basically did this for the TC, we have an openstack/governance repo
14:22:44 <russellb> and it works *really* well
14:22:52 <johnthetubaguy> a separate nova-bp repo might be good
14:23:02 <johnthetubaguy> russellb: cool
14:23:17 <sdague> dripton: it's not really a different process
14:23:21 <russellb> dripton: i think all projects have this problem, i think it's good to experiment with solutions.  someone has to lead the way
14:23:30 <russellb> i still think we'd use the blueprints system for status tracking
14:23:31 <sdague> because there is no commonality on *how* blueprints get reviewed
14:23:41 <russellb> right ... it's about the review side
14:23:59 <PhilD> @sdague - that's part of the problem
14:24:20 <sdague> PhilD: agreed, but the reason we have that problem is no ones found a system that works
14:24:33 <russellb> and storyboard isn't coming out tomorrow
14:24:40 <sdague> and gerrit is a really good tool for reviewing things
14:24:41 <russellb> but even with that, we may still like gerrit on the review side, i dunno
14:24:55 <russellb> sdague: i think we should take this idea to a wider audience
14:25:00 <sdague> russellb: agreed
14:25:04 <PaulMurray> russellb sdague: some problems come from bp in common areas - things change as we go
14:25:10 <russellb> because if we want to try it for juno, we need to jump on it
14:25:40 <PaulMurray> review a single bp is one thing
14:25:43 <sdague> sure, you want to do that this week still, or not distract from FFE
14:25:51 <sdague> I can take some first pass on thsi
14:25:55 <russellb> sdague: that would be excellent
14:25:57 <PhilD> Maybe - I think the reason we still have the problem is that the code review is seen as the design review.  That probably worked in the early days, and still works on the smaller projects.   This is just a part of the project maturing
14:25:58 <sdague> and get it on the list for discussion
14:26:11 <russellb> sdague: and i think we should start it now, so we have time to imlpement it before juno reviews start
14:26:25 <russellb> right now i feel like "why the heck haven't we considered this already"
14:26:27 <sdague> sure, I'll look to get something on -dev tomorrow
14:26:31 <russellb> ok
14:26:55 <mriedem> this would have really helped with garyk's v3 diags blueprint since the design was in a wiki and comments were in the ML
14:26:56 <russellb> i think we'd get a lot wider participation in reviews this way too
14:26:58 <mriedem> which wasn't fun
14:27:02 <johnthetubaguy> PhilD: the blueprint is certainly where there is design review, but I don't feel we should stop that at the code review stage, just need to get better at the blueprint stage?
14:28:43 <garyk> one of the issues with the bp is that the interface is terrible.
14:28:47 <garyk> comments are hard to follow
14:28:48 <russellb> heh, yes
14:28:56 <russellb> gerrit would help that immensely
14:29:00 <garyk> i have now started to write my name and the date with bp comments
14:29:16 <garyk> in some blueprints i did not even get updates
14:29:19 <PhilD> That wouls be good a start - I'd like to see some point in the code review though where we can say "the design is agreed and locked from here in", and it takes more that a single -2 to block it from that point (for example)
14:29:50 <PhilD> Maybe this is to do in part with sponsorship of the BPs
14:30:03 <dripton> Maybe we need to make the BP approval deadline earlier in the cycle to force front-loading the design and design approval work?
14:30:19 <garyk> dripton: agreed
14:30:45 <dripton> Of course, the only guarantee is that whatever the deadline is, there will be people clamoring for extensions the next day.
14:30:46 <garyk> but there are N bps and M sponsors. problem is that N >> M. as a community we need to cide which BP's get preference
14:30:52 <johnthetubaguy> PhilD: not sure that feels right, feels too process heavy, and there are always exceptions
14:30:57 <sdague> yeh, once we have different mechanics, we can figure out different process
14:31:17 <sdague> like when BP review would have to be approved by
14:31:18 <sdague> etc
14:31:27 <sdague> but I think this would move the ball forward
14:31:37 <johnthetubaguy> sdague: +1
14:31:40 <russellb> +2
14:31:46 <russellb> like, i want it today
14:31:52 <johnthetubaguy> yeah
14:31:54 <PhilD> Agree there has to be a balance here between process, but any new process always feels heavy compared to anachy ;-)
14:32:17 <sdague> PhilD: we could all just Quake deathmatch for approvals :)
14:32:22 <russellb> lol
14:32:27 <russellb> old school
14:32:44 <PhilD> We used to just send a gunship - that's what I consider old school
14:33:36 <russellb> #topic open discussion
14:33:43 <russellb> we're pretty far off of the "icehouse" topic now, heh
14:33:46 <russellb> any other topics for today
14:33:47 <russellb> ?
14:33:48 <johnthetubaguy> o/
14:33:49 <BobBall> o/
14:33:52 <russellb> woah now
14:33:54 <russellb> go for it :)
14:33:57 <PhilD> BTW Monty tells me this will all be a lot easier when we move to StoryBoard
14:34:04 <BobBall> john got his hand up first :/
14:34:17 <johnthetubaguy> BobBall: that was for your topic :)
14:34:21 <dripton> russellb: Has anyone volunteered to put your review stats code up on OpenStack hardware?
14:34:22 <BobBall> oh haha
14:34:36 <russellb> dripton: no
14:34:53 <BobBall> yes - now that the XS CI has been running for a while, I wanted to know a) if there were any concerns that needed to be addressed for Icehouse
14:34:54 <russellb> PhilD: yeah, but can't bank on futureware
14:34:57 <dripton> I think I'll have to volunteer then.  I think those stats were giving people a bit of a carrot and we need that.
14:35:09 <russellb> BobBall: IMO, you're in the clear for Icehouse, just keep up the good work
14:35:23 <russellb> dripton: should be easy enough to run locally
14:35:32 <russellb> dripton: but that'd be great
14:35:38 <russellb> it's a matter of some puppetizing
14:35:41 <BobBall> In which case I'd ask b) what we need to do / show to suggest a vote to get voting +/-1 votes
14:35:54 <russellb> BobBall: for that, vote when you're ready to vote
14:36:03 <russellb> and if the votes suck, you'll get attacked by a mob
14:36:05 <russellb> so make sure they don't suck
14:36:18 <BobBall> We think we're ready, but the -infra team say that nova team need to vote and agree that the CI is stable enough! :)
14:36:22 <russellb> no need to be formal, i think we want the votes when you feel it's ready
14:36:26 <russellb> heh
14:36:36 <russellb> ok, point me to a gerrit review or wheverever I need to ACK it
14:36:44 <BobBall> Understood - will do.
14:36:48 <russellb> probably a good gate for them to have
14:36:51 <BobBall> That was easier than I thought! :)
14:36:52 <sdague> russellb: there has been so much bad on the 3rd party on neutron, infra is conservative now
14:37:00 <russellb> sdague: that makes sense
14:37:10 <russellb> sdague: any concerns here?
14:37:20 <sdague> nope, it's seemed sane to me
14:37:26 <russellb> i guess i like being able to ACK it in case bizarro CI wants to vote
14:37:49 <sdague> yep
14:38:05 <BobBall> *nod* well thanks for the ACK - I'll request voting permissions by email and paste your IRC ACK ;)
14:38:14 <russellb> heh that's fine
14:38:17 <russellb> or CC me and I can reply
14:38:19 <russellb> whatever is needed
14:38:23 <BobBall> Thanks.
14:38:53 <johnthetubaguy> BobBall: thats for the work you an matel did on this, really good to see it working now
14:39:00 <johnthetubaguy> lol, thanks^
14:39:01 <russellb> +1
14:39:30 <russellb> any other topics?
14:40:26 <russellb> alright then ... #openstack-nova always open for chatter if anything comes up
14:40:28 <garyk> i have an icehouse installation at a local college where we are using openstack as a teaching tool :)
14:40:28 <russellb> thanks everyone!
14:40:35 <russellb> garyk: awesome
14:40:57 <russellb> #endmeeting