21:00:14 <russellb> #startmeeting nova
21:00:15 <openstack> Meeting started Thu Dec 12 21:00:14 2013 UTC and is due to finish in 60 minutes.  The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:19 <openstack> The meeting name has been set to 'nova'
21:00:21 <russellb> hello, everyone!
21:00:25 <mriedem> hi
21:00:28 <n0ano> o/
21:00:32 <alaski> hi
21:00:33 <dripton> hi
21:00:41 <melwitt> hi
21:00:57 <cyeoh> hi
21:00:59 <russellb> #topic general
21:01:02 <mestery> o/
21:01:09 <russellb> only one thing for this section today from me ... meeting time
21:01:29 <russellb> i'm going to start a thread about starting to alternate the time to allow more people to attend
21:01:40 <russellb> no need to get into the specific time too much now because the people it helps the most aren't here :)
21:01:50 <dansmith> o/
21:01:50 <russellb> so we'll meet at this time every 2 weeks
21:01:54 <hartsocks> \o
21:02:05 <russellb> details TBD ...
21:02:09 <russellb> #topic sub-teams
21:02:13 <russellb> hartsocks: well hello!
21:02:20 * n0ano scheduler
21:02:28 * melwitt novaclient
21:02:43 <arosen> hi
21:02:45 <lifeless> o/
21:02:50 <hartsocks> russellb: sorry running late.
21:02:54 * russellb expects he may have caught hartsocks off guard
21:03:00 <russellb> n0ano: you can go :)
21:03:11 <n0ano> right, make me go first :-)
21:03:22 <n0ano> talked at the meeting about no-db and the forklift...
21:03:27 <russellb> some good scheduler forklift progress this week
21:03:51 <n0ano> the no-db has about 2 patches left, once they are submitted (within about a week) it should all be under review...
21:04:26 <russellb> is anyone committed to keeping the forklift repo in sync while it's in progress?
21:04:34 <russellb> you?  someone else?
21:04:50 <russellb> and are you looking at stackforge now?
21:04:54 <lifeless> we have the volunteers, I think we should submit the repo to gerrit asap
21:04:55 <n0ano> for the forklift, I've created the base scheduler tree, we should be about ready to create a stackforge project, lifeless should know if any other administrivia is needed
21:05:08 <lifeless> probably need the client tree to, I sucked this week
21:05:10 <russellb> ok cool
21:05:12 <lifeless> I will get it done today
21:05:27 <n0ano> lifeless, I created the bare bones client tree and added it to the config file
21:05:29 <russellb> ok, client is easier
21:05:35 <lifeless> n0ano: oh cool, ok
21:05:37 <russellb> i think it's still included in the repo n0ano just did
21:05:39 <lifeless> so lets get infra on that
21:05:46 <russellb> oh nice, you did that too?
21:05:57 <russellb> is it just nova/scheduler/rpcapi.py ?
21:06:03 <n0ano> I'm an animal, what can I say :-)
21:06:13 <russellb> and the associted test file
21:06:24 <lifeless> plus setup.py/.cfg etc machinery?
21:06:39 <n0ano> russellb, even less, just the top level text files (licensing and what not), the rest will be new files, should be created though the gerrit process
21:06:45 <comstud> o/
21:07:03 <russellb> hmm, no
21:07:11 <russellb> i think we need to keep the history of rpcapi.py
21:07:15 <russellb> that's the client code
21:07:17 * beagles slinks in late
21:07:44 <n0ano> hmm, is that file already in the server tree?  If not, I can add it to the client tree
21:07:52 <russellb> yes, it's in the server tree now probably
21:08:03 <lifeless> it shouldn't be though, should it?
21:08:03 <russellb> but it's the client code everything else uses to talk to the scheduler
21:08:09 <russellb> i didn't catch that before, sorry
21:08:35 <russellb> not a huge deal if we just git rm it from the server tree
21:08:46 <n0ano> remember, it's all scripted, NP - so you want to remove that file from the server tree and make it part of the client tree
21:08:53 <lifeless> please
21:08:53 <russellb> yeah
21:09:07 <russellb> thanks a bunch for doing this :)
21:09:09 <lifeless> the goal is two trees; one with the client, one the server both can run their own unit tests
21:09:23 <n0ano> NP, the config file changes stay the same, I'll let lifeless know when the trees are ready
21:09:24 <russellb> i expect we'll have some work to do to get the tests running again
21:09:31 <russellb> but we're close to the right base to start with
21:09:32 <lifeless> if they can't run unit tests we'll make all the jobs nonvoting so we can iterate
21:09:43 <russellb> works for me
21:10:05 <russellb> so good progress on two major things in scheduler land
21:10:09 <russellb> anything else for today?
21:10:14 <n0ano> that's it for now
21:10:17 <russellb> great thanks!
21:10:19 <russellb> melwitt: hi!
21:10:30 <russellb> speaking of clients, novaclient!
21:10:53 <melwitt> hi all, I have the novaclient report for this week:
21:10:54 <melwitt> open bugs, 118 !fix released, 77 !fix committed
21:10:54 <melwitt> 20 new bugs
21:10:54 <melwitt> 0 high bugs
21:10:54 <melwitt> 31 patches are up, 7 WIP, everything been pretty active -- prompt reviews and approvals, lots of v3 api activity.
21:10:54 <comstud> let's have one
21:11:31 <russellb> sounds like great progress all around
21:11:40 <russellb> more progress on bug triage i see, thanks a bunch
21:11:47 <russellb> any major concerns?
21:12:01 <melwitt> no, I think things are going pretty well
21:12:11 <russellb> so the 77 !fix committed number
21:12:20 <russellb> does that mean there are 77 bug fixes that haven't been released?
21:12:26 <russellb> or?
21:12:38 <russellb> seems high since we did a release around the havana release
21:12:48 <melwitt> ah, no. I wasn't sure how to represent "open" bugs. 77 is the number of bugs that are neither fix committed nor fix released
21:13:04 <russellb> ok
21:13:18 <russellb> so we have 118 total open, 77 after you take out the ones with fixes committed?
21:13:24 <melwitt> right
21:13:26 <russellb> got it
21:13:30 <melwitt> I consider those like "fixed"
21:13:38 <russellb> fixed but not released, yeah
21:13:55 <shanewang> melwitt: did you have any link to query "fix released", "fix committed"?
21:13:55 <russellb> so 41 fixes not released then
21:13:57 <russellb> something like that
21:14:27 <russellb> btw, timing of novaclient releases since i've been doing them has been roughly ... when someone asks for it
21:14:31 <russellb> so if you have better ideas, let me know, heh
21:14:45 <melwitt> haha ok
21:14:52 <russellb> anything else?
21:15:13 <melwitt> I think that's it. I'll continue going through the bugs, try to trim all that down
21:15:20 <russellb> thanks!
21:15:23 <russellb> hartsocks: you're up
21:15:27 <hartsocks> cool
21:15:39 <hartsocks> So, we have 2 BP for Icehouse already approved and ready to go.
21:15:48 <russellb> woo
21:15:51 <hartsocks> I've got one on my plate that I need to finish.
21:16:11 <russellb> how's the minesweeper
21:16:11 <hartsocks> I'll have to solicit some help on that later today or tomorrow if someone's got time/interest.
21:16:19 <russellb> what kind of help?
21:16:44 <hartsocks> on that topic, I just need to figure out how best to work with the oslo component I want to tie in with.
21:17:01 <russellb> ok
21:17:04 <hartsocks> that's a bit of a can-o-worms so I'll just leave it.
21:17:08 <russellb> k :)
21:17:46 <russellb> hartsocks: see my minesweeper question?
21:17:52 <hartsocks> We have a small patch in flight related to CI stability…
21:18:04 <russellb> OK, patch to nova?
21:18:06 <hartsocks> I *could* call it out …
21:18:18 <russellb> or something else?
21:18:36 <russellb> yeah now is a good time to call out high priority things, especially like that
21:18:38 <hartsocks> ugh. Taking too long for me to hunt up the link.
21:18:48 <russellb> ok, feel free to bring it to open discussion then
21:18:55 <russellb> anything else you wanted to mention?
21:18:55 <hartsocks> We do have 7 high priority bugs. I spammed that out yesterday.
21:19:02 <hartsocks> that's all for now.
21:19:03 <russellb> yep, appreciate the reports
21:19:06 <russellb> k, thanks!
21:19:07 <russellb> #topic bugs
21:19:13 <russellb> how bad is the nova bug queue this week?
21:19:24 <russellb> lifeless: any bug topics?
21:19:27 <lifeless> hi yes
21:19:38 <lifeless> so I will have an email out later today
21:19:47 <russellb> looks like there's been some triage progress in the last week
21:19:47 <lifeless> about what I want to do to the bug triage process
21:19:52 <russellb> cool
21:19:59 <russellb> an do you think we need a bug day to play catchup?
21:20:00 <lifeless> bug basically it has way to much double handling
21:20:12 <lifeless> so it's super inefficient - it's boiling the ocean
21:20:22 <lifeless> can I run a high level replacement past the meeting?
21:20:29 <russellb> sure
21:21:01 <lifeless> My idea is that triage only  touches an untriaged bug once: we do everything we can do it and then either:
21:21:07 <lifeless> A) leave it incomplete [pending user input]
21:21:21 <lifeless> or B) leave it triaged [coarse priority set]
21:21:32 <lifeless> or C) we bounce it to ask.openstack.org
21:21:44 <lifeless> the only time we touch it twice would be if it goes into A)
21:21:55 <mriedem> (c) would be like usage help questions?
21:21:59 <lifeless> yeah
21:22:02 <mriedem> that we mark as invalid and send them to the ML now
21:22:21 <russellb> the idea with the tagging was just that there are lots of people qualified to triage subsets of the bugs
21:22:22 <lifeless> the list? Ok sure
21:22:22 <mriedem> so we have to repost it to ask.openstack.org or make the reporter do it?
21:22:29 <lifeless> russellb: so I've been poking around
21:22:43 <russellb> not sure that's been happening in reality
21:22:54 <lifeless> russellb: and I don't see at the level of 'assess importance' that we need deep plumbing in each hypervisor
21:23:00 <mriedem> when i do triage i definitely tag stuff, but i don't know if they get love after that
21:23:05 <lifeless> we only get ~ 10 new bugs a day.
21:23:14 <lifeless> look ^ stats
21:23:15 <russellb> only 10 a day, heh
21:23:46 <lifeless> so - the goals:
21:23:59 <lifeless> - ensure users don't get stuck in limbo - they either get told 'its a real bug' or
21:24:03 <lifeless> its a usage question'
21:24:11 <lifeless> - we create a pool of low hanging fruit
21:24:19 <lifeless> - vendor teams have bugs routed to them
21:24:57 <mriedem> hmmm, determining if something is a real bug could be hard w/o an env to recreate on
21:25:02 <lifeless> there's a bunch of bug management stuff we've been categorising as triage - like aging out bugs - that isn't triage - I want to build a separate process for that
21:25:21 <russellb> ok
21:25:27 <lifeless> mriedem: so thats where you make a judgement call
21:25:32 <cyeoh> so I do see a reasonable steady stream of bugs tagged api but not triaged. If we say that people have to triage at the same time as tag and they're not able to, they might just get left in limbo
21:25:43 <russellb> well i'm happy to try whatever right now
21:25:55 <russellb> whatever helps engage more people to get things touched
21:26:04 <lifeless> ok, so I'll have a draft of what I'd like to try up to the list today
21:26:14 <russellb> ok sounds good
21:26:21 <lifeless> tldr;:
21:26:31 <lifeless> - much simpler /triage/ process and a group focused on making that really work
21:26:31 <mriedem> qa team might have good input on this since they have to do this all the time for code they don't work on
21:26:49 <russellb> k, will look out for the post
21:26:49 <lifeless> - a separate maintenance process for aging out / reviewing idle-assigned etc.
21:27:04 <russellb> another bug thing i wanted to bring up was the gate affecting stuff
21:27:12 <russellb> there's been some ML posts on it the last couple days
21:27:24 <russellb> also if you look at https://bugs.launchpad.net/nova/+bugs, look at everything marked CRITICAL
21:27:35 <russellb> if anyone has cycles, we could use some help on those things
21:27:49 <lifeless> I did want to ask about this though:
21:27:51 <lifeless> '
21:27:51 <lifeless> If the bug contains the solution, or a patch, set the bug status to Triaged '
21:28:14 <lifeless> I just can't understand how that makes sense; it doesn't fit any definition of triage I've ever encountered
21:28:41 <mriedem> well it's either triaged or confirmed at that point by the reporter
21:28:50 <mriedem> why they don't push the patch makes me wonder sometimes
21:28:54 <lifeless> more context
21:29:17 <lifeless> the 'BugTriage' page treats Triaged as 'has a patch'
21:29:33 <lifeless> for instance - 'We should review if the patch looks indeed like a patch, and if yes, set the bug status to Triaged to show that it comes with a likely solution, ready to be implemented. '
21:29:51 <lifeless> I just wanted to see if the nova folk share that understanding, or if it's a surprise :)
21:30:07 <mriedem> personally i don't have the bug triage wiki page memorized
21:30:13 <lifeless> The outside-openstack understanding of triaged is 'the urgency is known'
21:30:26 <lifeless> I want to make sure I'm solving the actual problem
21:30:28 * russellb hasn't really used triaged much, just confirmed
21:30:33 <devananda> so, my interpretation -- which doesn't match the wording well, but makes more sense to me -- has been confirmed = "yep, it's a bug!" vs. triaged = "AND here's a reasonable proposal on how to solve it"
21:30:35 <mriedem> yeah, i don't use triaged much
21:30:42 <russellb> devananda: +1
21:30:46 <lifeless> devananda: thats not what triaged means in LP though
21:30:57 <lifeless> devananda: it means 'importance has been assessed'
21:31:12 <lifeless> basically the standard emergency ward definition
21:31:17 <russellb> heh just don't think we've used it that way
21:31:42 <lifeless> ok, so we may end up ratholing around that a little on the list. Thanks.
21:31:53 <russellb> alright, let's move on
21:31:55 <russellb> #topic blueprints
21:32:01 <devananda> lifeless: that is redundant. [confirmed, no pri] vs [confirmed, has a priority] is sufficient triage. there is no need for a ternary state
21:32:11 <russellb> general announcement, if you have blueprints targeted to icehouse-2, please check their status and make sure they are approved
21:32:11 <shanewang> lifeless: is triaged "confirmed by the supervisor"?
21:32:16 <russellb> if not, they may be waiting on your feedback
21:32:33 <russellb> I'm going to move everything not approved to icehouse-3 a week from today
21:32:50 <russellb> more details here:
21:32:51 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/021820.html
21:33:31 <russellb> one blueprint i wanted to bring up is the GCE API
21:33:33 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/021469.html
21:33:56 <russellb> I've recommended that they work on getting it into its own stackforge project for now, because i'm sensing very little support for this
21:34:07 <russellb> and in that message linked above, i'm asking for anyone that wants this in nova to speak up
21:34:20 <russellb> i think we as a team need to be on board with maintaining this, at a minimum from a review perspective
21:34:46 <russellb> point of bringing it up today was to raise awareness of the fact that i want that feedback
21:35:06 <russellb> anyone have thoughts on that right now?
21:35:12 <mriedem> +1 to stackforge, i think that's going to be the route for most new stuff like new drivers
21:35:24 <cyeoh> as I sort of mentioned in that thread, I don't think they've come up with a good reason for it needing to be in the Nova tree.
21:35:26 <mriedem> then you get 3rd party CI going and prove it and incubate before getting promoted
21:35:27 <russellb> i wouldn't say that as a blanket statement to all new things
21:35:37 <russellb> mriedem: oh, right
21:35:39 <lifeless> devananda: right, this is an open bug on LP
21:35:48 <cyeoh> since they're saying it can just sit on top of the nova rest api
21:35:51 <russellb> cyeoh: they even agreed that the other way was better
21:35:57 <russellb> so not making a good case :)
21:36:12 <mriedem> russellb: stackforge for anything new that requires 3rd party CI, maybe that makes more sense
21:36:15 <russellb> so regardless of whether it ends up in nova, stackforge + CI is a good start
21:36:18 <russellb> mriedem: +1
21:36:36 <russellb> but right now i'm not sensing much support of it ending up in nova in the near term
21:36:43 <russellb> any other blueprints folks want to discuss today?
21:36:53 <russellb> #link https://launchpad.net/nova/+milestone/icehouse-2
21:37:02 <russellb> 92 blueprints targeted to icehouse-2 right now :)
21:37:06 <lifeless> shanewang: yes, bug supervisor == triager
21:37:10 <russellb> only 4 that reviewers have committed to
21:37:32 <russellb> the core sponsorship thing doesn't really seem to be taking off
21:37:55 <russellb> i still like the idea though
21:38:00 <russellb> maybe it'll just take longer for us to get used to it
21:38:26 <dansmith> has anyone other than john and I signed up for one?
21:38:41 <alaski> I have a couple
21:38:47 <dansmith> maybe we just need to be a little more vocal with the core folks
21:38:51 <dansmith> alaski: ah, right
21:39:08 <russellb> i have a couple
21:39:18 <devananda> russellb: i'd like to bring up the deprecate-baremetal BP briefly
21:39:18 <russellb> some that i have signed up for have just 1 though
21:39:23 <russellb> devananda: sure
21:39:42 <devananda> russellb: with the BP-needs-a-reviewer-signup thing, we don't have one yet :)
21:39:56 <russellb> do you expect the driver to be ready for merging in icehouse-2?
21:40:04 <devananda> russellb: also, I'd like some guidance on how ya'll would like the patch broken up. adding a new driver is, well, a lot of code to review at once
21:40:20 <devananda> russellb: it should be functional by then
21:40:32 <russellb> not sure how to break it up really ...
21:40:42 <russellb> unless you did it by features
21:40:50 <devananda> russellb: i'm not sure whether it'll be polished and all by end of jan, though
21:40:56 <mriedem> new driver?
21:41:00 <devananda> ironic
21:41:10 <russellb> polished by end of jan puts it in icehouse-3
21:41:12 <devananda> supplanting baremetal driver
21:41:13 <russellb> should we retarget?
21:41:22 <devananda> russellb: deadline is jan22, no?
21:41:29 <russellb> for merging
21:41:34 <russellb> yeah
21:41:38 <russellb> hopefully ready for review a little sooner
21:41:41 <mriedem> so should a nova ironic driver start in stackforge to get CI going first?
21:41:41 <russellb> we can leave it for now
21:41:53 <russellb> i don't want to commit to reviewing for icehouse-2 if you're telling me it'll be ready for review the day before :)
21:42:01 <devananda> heh, fair
21:42:13 <russellb> based on that timeline, i'd sponsor for icehouse-3
21:42:14 <devananda> so it may be ready for some reviews now -- it's already ~ 700 LOC
21:42:25 <devananda> and not feature complete yet ...
21:42:54 <russellb> mriedem: good question on CI
21:42:58 <mriedem> this also reminds me, we don't have a core set of required APIs for virt drivers...
21:43:01 <devananda> thus my question about how / whether to break it up
21:43:02 <russellb> devananda: how does CI look for this driver?
21:43:10 <mriedem> so if you stagger in the reviews for a new virt driver and they don't all make core for the release, do you drop the entire driver?
21:43:12 <russellb> mriedem: yes.  we need one.
21:43:46 <devananda> russellb: current CI for this is "none" because Ironic is still workin gout the deployment API
21:43:54 * russellb nods
21:44:02 <russellb> so ... we have this requirement for the release, that CI exists or the driver gets pulled
21:44:07 <mriedem> hmm, so then how does that fit into the i2 driver deprecation plan?
21:44:10 <devananda> russellb: unless some mirantis folks really work quickly, I don't think we'l lhave the level of CI I want until after icehouse release
21:44:13 <devananda> unfortunately
21:44:22 <devananda> (or someone else steps up to do it)
21:44:33 <russellb> OK, that could realistically mean the driver slips to Jeckyll
21:44:34 <dansmith> mriedem: this has been coming for a while, and replaces the baremetal driver, which we're eager to drop
21:44:49 <mriedem> dansmith: yeah, but it still requires CI to live right?
21:44:56 <mriedem> 3rd party CI if community infra doesn't host that?
21:45:12 <devananda> mriedem: this would mean an Icehouse release without either baremetal or ironic support .....?
21:45:16 <dansmith> mriedem: I think it will get a little slack on the deadline, I'm guessing
21:45:25 <mriedem> so are we talking double standards here?
21:45:27 <dansmith> mriedem: we can't drop both
21:45:32 <russellb> argh, i don't like the idea of not having either
21:45:43 <mriedem> slippery slopes...
21:45:45 <russellb> maybe we grant ironic an exception given the awkward timing for the transition
21:45:59 <dansmith> I think the assumption is that ironic/BM is a key feature for openstack,
21:46:11 <dansmith> and we're in a sticky situation right now so it has to get a little bit of a pass for the time being
21:46:13 <devananda> mriedem, russellb -- if you consider tripleo's testing as "third party ci" then maybe that is sufficient
21:46:18 <russellb> devananda: yes, i do
21:46:27 <devananda> that's all based on nova-baremetal today
21:46:35 <russellb> i think we would consider that significant enough CI progress to not drop it
21:46:39 <devananda> great
21:46:42 <mriedem> ok, i guess in general i'm interested in where the vmware, xenapi, docker, and hyperv teams are with CI
21:46:59 <mriedem> maybe that's for open discussion
21:47:21 <devananda> AIUI, lifeless plans to switch tripleo to use the ironic driver as soon as it works (where works == does everything baremetal does for tripleo)
21:47:21 <russellb> vmware has minesweeper that they're actively building up
21:47:26 <lifeless> yeah
21:47:27 <dansmith> russellb: until it's reporting on each nova patch, I don't think the tripleo testing should "count" but I also think we have to consider this an exception :)
21:47:30 <russellb> xenapi has some good progress integrating into upstream CI
21:47:36 <russellb> docker and hyperv, haven't actually seen anything yet
21:47:36 <lifeless> also we hope to bring up tempest tests against ironic clouds asap
21:47:40 <devananda> russellb: so the ironic driver will get third-party CI at that point in time
21:47:41 <lifeless> separate to tripleo switching
21:47:45 <russellb> dansmith: fair
21:47:45 <mriedem> russellb: but xenapi is using smokestack right?
21:47:55 <russellb> mriedem: right now, but they're working on changing that
21:48:00 <russellb> integrating into infra
21:48:05 <lifeless> when the redhat region comes in, we should be able to get 'check' status tests infra - not thirdparty.
21:48:09 <mriedem> ok, because smokestack doesn't run tempest afaik
21:48:19 <russellb> mriedem: yep
21:48:25 <mriedem> and vmware has to run on all patches per the requirements
21:48:32 <russellb> yes
21:49:03 <mriedem> s/vmware/vmware, hyperv, docker, xenapi, everything/
21:49:18 <russellb> yes yes
21:49:20 <russellb> :)
21:49:25 <russellb> any other blueprints?
21:49:35 <lifeless> baremetal-preserve-ephemeral
21:49:44 <lifeless> we have a sketch of all the bits up in gerrit
21:49:55 <lifeless> would love someone to cast an eye over the code and comment on general direction
21:50:03 <russellb> #link https://blueprints.launchpad.net/nova/+spec/baremetal-preserve-ephemeral
21:50:19 <lifeless> maybe someone has since I asked about this on IRC yesterday - if so great,a nd sorry for the repeated q ;)
21:50:29 <russellb> i'll sponsor that
21:50:36 <russellb> if it's pretty far along already
21:50:50 <lifeless> yeah
21:50:56 <russellb> assuming it's in the right direction, not a whole bunch left to do?
21:51:00 <lifeless> we need comment on the driver API change
21:51:15 <lifeless> we need to know if the HTTP API change is ok as is or needs to be a new extension
21:51:29 <russellb> for v2, without even looking, probably a new extension
21:51:50 <russellb> allows you to discover that the feature is present
21:52:05 <lifeless> not a change to the rebuild extension?
21:52:21 <russellb> well, the code could be a change to rebuild, where it checks to see if this other extension is loaded
21:52:28 <russellb> search for extended-services (i think)
21:52:33 <cyeoh> lifeless: for v2 its normally a dummy extension (no content)
21:52:38 <russellb> for an example of where the "extension" is just an empty dummy thing
21:52:59 <russellb> and then some other code does something like ... if extension_is_loaded('my-thing'): support_my_thing()
21:53:02 <lifeless> I will look and see what we've got, but if one of you could comment directly on the review that would be awesomer
21:53:06 <russellb> k
21:53:33 <cyeoh> lifeless: do you have a link to which review?
21:54:01 <russellb> https://review.openstack.org/#/q/topic:bp/baremetal-preserve-ephemeral,n,z
21:54:04 <russellb> is the series ...
21:54:12 <cyeoh> thx!
21:54:27 <lifeless> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/baremetal-preserve-ephemeral,n,z
21:54:34 <russellb> i can't find the API patch in there though
21:54:53 <lifeless> huh, it was
21:55:00 <russellb> anyway
21:55:03 <russellb> we'll sort it :)
21:55:06 <russellb> #topic open discussion
21:55:09 <russellb> 5 minutes!
21:55:32 <lifeless> I will find it and link in -nova
21:55:42 <russellb> sounds good
21:55:56 <cyeoh> just a reminder if people could remember to look at python-novaclient patches too? (And I'm not just saying that because I have a bunch of patches with one +2 sitting in there :-)
21:56:01 <mrodden> i (and some others at IBM) are sponsoring a senior project team a university, and I was looking for idea of blueprints in OpenStack that would be good to have them work on
21:56:12 <mrodden> at a university even...
21:56:18 <russellb> mrodden: can it be ... fix a bunch of bugs?  :-p
21:56:25 <russellb> but that's cool
21:56:27 <mrodden> that will probably be the first phase yes
21:56:28 <mrodden> :)
21:56:30 <mriedem> i suggested infra/qa stuff
21:56:49 <mriedem> but that's a bit dirty probably
21:57:00 <mrodden> was looking for something that would be achievable as i don't know how familiar with python or openstack they will be
21:57:02 <mriedem> unless it's some neato gadget for helping automate something with bugs
21:57:10 <russellb> cyeoh: indeed ... also, pro tip ... set up a "my review queue" bookmark... example: https://review.openstack.org/#/q/project:openstack/nova+OR+project:openstack/python-novaclient,n,z
21:57:23 <russellb> but with all the projects and branches you care to review
21:58:02 <russellb> mriedem: thierry just posted an infra project idea to the -infra list
21:58:15 <lifeless> russellb: cyeoh: Id33d5d4107f89814842a3f0b7f33690dd7e3aadc
21:58:18 <mriedem> mrodden: have the interns automate the release process :)
21:58:18 <lifeless> bah, echannel
21:58:31 <mriedem> no more MP branch
21:58:35 <russellb> mriedem: the idea was infra-izing the schedule of #openstack-meeting and #openstack-meeting-alt
21:58:39 <russellb> should check it out
21:59:03 <mriedem> mrodden: ^ :)
21:59:08 * mrodden shuffles through -infra mail
21:59:25 <russellb> mriedem: mrodden http://lists.openstack.org/pipermail/openstack-infra/2013-December/000517.html
21:59:32 <mrodden> sweet thx
21:59:54 <mriedem> with more projects moving to adjust for all timezones that could help a lot
22:00:20 <russellb> we're out of time, off to #openstack-nova if anyone still wants to chat
22:00:21 <russellb> thanks everyone!
22:00:23 <russellb> #endmeeting