21:08:13 <russellb> #startmeeting nova
21:08:14 <openstack> Meeting started Thu Oct 25 21:08:13 2012 UTC.  The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:08:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:08:16 <openstack> The meeting name has been set to 'nova'
21:08:39 <markmc> howdy
21:08:44 <russellb> Alright, nova meeting time.  Who's around?
21:08:45 <dansmith> <-- here
21:08:48 <rmk> <-- here
21:08:51 <mikal> I'm here.
21:08:52 <russellb> Agenda: http://wiki.openstack.org/Meetings/Nova
21:09:10 <mtreinish> I'm here
21:09:12 <dprince> hey
21:09:28 <russellb> #topic features in nova-network
21:09:31 <sdague> <-- here
21:09:43 <russellb> so this is something I had a question about because of https://review.openstack.org/#/c/14518/
21:09:48 <markmc> #link https://review.openstack.org/14518
21:09:52 * mikal looks at the review
21:10:00 <cburgess> <-- here
21:10:02 <russellb> I'd like to see focus on quantum and nova integration with quantum
21:10:12 <markmc> abstract all the things
21:10:14 <russellb> should we lock down the nova networking code?
21:10:19 <rmk> We've actually put off submitting enhancements we've made to nova-network, so this general topic is a good one to discuss
21:10:57 <rmk> I think nova-network and quantum largely have different groups of people working on them and looking at them
21:11:16 <russellb> and i think that's not very helpful toward the long term goal
21:11:30 <sdague> russellb: that's more of a cleanup, no?
21:11:32 <markmc> russellb, at a first glance, it doesn't look very invasive and mirrors the direction quantum is going
21:11:33 <mikal> Are there people who can't yet use quantum for some reason?
21:11:38 <rmk> Sure but that's the reality, primarily because people are still using nova-network in production now
21:11:42 <rmk> mikal: floating IPs
21:11:45 <sdague> and I agree that it's not all that useful that these groups are distinct
21:11:47 <mikal> i.e. are we blocking people who are stuck without quantum for now?
21:11:48 <cburgess> mikal: yes floating IPs
21:12:09 <markmc> in general, a policy of not adding tonnes of features to nova-network makes sense I think
21:12:16 <russellb> sdague: it's not so much about this patch ... just made me thing about the general issue before something big comes up
21:12:21 <sdague> russellb: agreed
21:12:26 <russellb> ok, but this particular thing is fine since it's not so big perhaps
21:12:37 <rmk> markmc: Tons yes but fitting/suitable enhancements, why not?
21:12:39 <mikal> markmc: I agree, but I think we shouldn't block people who have legitimate reasons to need to tweak nova-network for now
21:13:08 <markmc> yep, agree
21:13:12 <mikal> We could ask that new features in nova-network get an equivalent added to quantum as part of the cost of the nova-network update?
21:13:13 <russellb> yeah, tweaks are ok ... just hopefully nothing hugely invasive and drastic
21:13:20 <rmk> For example, we have code which allows an existing tenant to consume multiple layer3 networks on a single vlan
21:13:22 <sdague> mikal: I think that's a good call
21:13:40 <rmk> We'd submit it and I suspect a lot of people would use it but we weren't sure whether we should with Quantum being developed
21:13:45 <mikal> sdague: it might be a bit unfair to demand someone learn two code bases though just to fix their production problem...
21:13:58 <mikal> Perhaps just require a quantum bug be filed before the nova-network code goes in?
21:14:02 <markmc> rmk, that's the kind of thing I'd be more wary of
21:14:10 <markmc> rmk, e.g. does quantum allow what you want?
21:14:15 <rmk> mikal: That's reasonable
21:14:22 <rmk> markmc: I don't believe Quantum does this
21:14:28 <rmk> Not the way we have done it, to conserve use of VLANs
21:14:29 <markmc> rmk, and how invasive (likely to break) is it to nova-network?
21:14:47 <markmc> well, quantum has a "provider networks" extension now
21:14:57 <markmc> which might help, or at least get you closer
21:15:03 <rmk> Sounds like it will help for sure
21:15:06 <cburgess> I would tend to agree that big features or substation changes like the multiple L3 sharing (which I wrote for us) should be done in quantum and a request made to be added to nova-network if its really needed.
21:15:40 <russellb> so sounds like we're roughly on the same page on this topic
21:15:51 <cburgess> However clean and flexability of config such as where your gateway (already in Folsom) and your DHCP server live (this patch we are discussing) should probably be added to nova-network to continue to allow flexability.
21:15:51 <russellb> no hard rules need to be set I think
21:15:54 <rmk> How about a general policy of being open to changes, but will discuss each submission?
21:16:02 <russellb> but good to review it so we're reviewing consistently
21:16:15 <markmc> yeah, good topic
21:16:25 <russellb> I'd say nova-core should watch out for anything that may be considered too big and bring it up in this meeting
21:16:36 <mikal> Agreed
21:16:50 <sdague> +1
21:17:00 <russellb> #topic cells status
21:17:02 <russellb> comstud: around?
21:17:27 <russellb> this was something we discussed having as a weekly agenda item until merged
21:17:40 <russellb> status: not yet re-proposed?
21:17:41 <mikal> If he's not around, someone should take an action to ping comstud and ask him how its going and how we can help.
21:18:17 <russellb> sure, i can do that.
21:18:31 <russellb> #action russellb to ping comstud about cells status
21:18:46 <russellb> #topic nova bugs status
21:18:55 <russellb> last thing, another topic for every week
21:18:58 * markmc phears
21:19:01 <russellb> i.e. "how behind on bugs are we"
21:19:05 <mikal> There are a lot of untriaged bugs, which is no surprise
21:19:19 <russellb> http://webnumbr.com/untouched-nova-bugs
21:19:21 <markmc> 40 ... not great, not terrible
21:19:28 <russellb> looks like someone or some people have been doing some triage
21:19:30 <rmk> yeah, new release and conference last week tied most of us up
21:19:34 <russellb> so thanks to whoever has been working on it
21:19:35 <mikal> I think the intention was also to call out people who were doing a good job, but I don't think we actually have a tool to do that at the moment.
21:19:41 <russellb> correct
21:19:50 <markmc> yeah, stats would be awesome
21:19:58 <russellb> but also raise awareness if it gets too high so we can all pitch in a bit in the coming week
21:20:13 <mikal> There's a LP API, right? I've never used it.
21:20:27 <russellb> if everyone could try to triage just a few every week, we'd be *much* better off
21:20:30 <markmc> yeah, we use it for release management stuff
21:20:32 <russellb> so, reminder, try to triage a few this week
21:20:34 * markmc digs up a link
21:20:37 <sdague> mikal: there is, it's used in markmc's gitdm fork
21:20:51 <markmc> lp:~openstack-release/+junk/openstack-lp-scripts
21:21:00 <markmc> bunch of lp code in their
21:21:04 <markmc> oh yeah, gitdm too
21:21:13 <russellb> anyone interested in taking on writing a script to gather some stats?
21:21:25 <markmc> https://github.com/markmc/openstack-gitdm/tree/master/launchpad
21:21:28 <russellb> seems like something that another launchpad user may have written before, too ... would be worth searching around
21:21:33 * markmc will prolly get to it eventually but ...
21:21:50 <russellb> author of the script gets to weight their own stats!
21:21:54 <mikal> LOL
21:22:08 <markmc> we should discount self-triage
21:22:17 <markmc> i.e. I file a bug and triage it myself
21:22:22 <mikal> I will take a look, but no promises. I start travelling again tomorrow.
21:22:33 <russellb> cool, understood
21:22:38 <russellb> it's a "nice to have" anyway
21:22:45 <russellb> but would be a fun side project to hack up
21:23:03 <mikal> I'll take it to the TC as a proposed core project.
21:23:04 <russellb> if someone makes good progress, ping the ML so we're don't dupe too much effort
21:23:10 <russellb> ha
21:23:15 <markmc> mikal, we should talk to the board first
21:23:27 <mikal> Board smord
21:23:31 <sdague> russellb: I might get some time tomorrow afternoon, and I've been using markmc's scripts so getting a little familiar with it
21:23:38 <russellb> great
21:23:46 <sdague> so put me in the same "will try to play" camp as mikal
21:23:58 <russellb> #topic open floor
21:24:02 <russellb> anything else?
21:24:21 * dansmith dances on the open floor
21:24:24 <mikal> We have a lot of queued reviews
21:24:31 <russellb> how many?
21:24:45 <mikal> Ummm, two and a bit screens in gerrit
21:24:48 <sdague> maoy about? I was hoping there would be a service group patch rev to fix a couple of minor things
21:24:54 <russellb> yeah, a bit higher than we usually keep it
21:24:55 <comstud> russellb: i am here
21:24:58 <comstud> (now)
21:25:04 <russellb> comstud: ah, great!
21:25:17 <markmc> "Found 61 items for review"
21:25:17 <mikal> 70 apparently
21:25:20 <russellb> comstud: we have "cells" as a topic each week so we can work together to move it forward and get it in
21:25:27 <russellb> #topic cells status
21:25:30 <comstud> ok yep
21:25:32 <sdague> baremetal needs some eyes as well, I think general agreement was to help them clean up and get in
21:25:39 <russellb> comstud: planning to propose soon?
21:25:42 <maoy> sgague: completely overwelmed by other things.. hopefully to get service group thing done tomorrow
21:25:51 <comstud> i had to travel... but I am working on rebasing it against latest master
21:25:52 <sdague> maoy: cool
21:25:54 <comstud> few new conflicts
21:26:03 <comstud> And I want to attempt to split the patch up in some way
21:26:18 <russellb> comstud: k ... well i'm planning to jump in to help review once it's to that point
21:26:21 <sdague> comstud: someone was going to propose in devstack support as well too right? so we can test the patch during review?
21:26:21 <comstud> was working on this today.. but haven't gotten too far yet due to meetings
21:26:42 <comstud> sdague: i was actually just helping with that as well
21:26:48 <comstud> it's getting close
21:26:49 <russellb> nice
21:26:51 <sdague> comstud: ok, cool.
21:26:58 <russellb> cool, so perhaps proposed by next meeting then?
21:27:10 <comstud> i can't speak for devstack
21:27:19 <comstud> but definitely for the cells code itself
21:27:22 <maoy> sdague: the subscribe API issue in service group Eric and some other guy brought up might deserve more time to think
21:27:34 <sdague> maoy: ok
21:27:39 <russellb> great, so then starting next week we can spend time each week digging through whatever review issues have come up to help move it along
21:27:59 <russellb> thanks for the update, comstud
21:28:01 <comstud> thankfully i'm not traveling next week!
21:28:04 <comstud> np
21:28:06 <russellb> #topic open floor
21:28:45 <sdague> #link https://review.openstack.org/#/c/13920/ - is the first bare metal review, could use more eyes
21:28:55 <russellb> i guess baremetal is another big one we should have on our list to talk about each week ...
21:29:28 <mikal> russellb: for sure
21:30:09 <russellb> so baremetal patch #1 has a +2 from vish
21:30:19 <mikal> Linky?
21:30:27 <russellb> #link https://review.openstack.org/#/c/13920/
21:30:47 <russellb> markmc: you had some concerns about this code, want to review again?
21:31:02 <russellb> (next week or whatever, i know you're busy this week)
21:31:03 <markmc> russellb, I will do if it's still there when I come back from holidays
21:31:23 <russellb> k.
21:31:57 <russellb> any other topics?
21:32:33 <russellb> ok, well thanks for coming everyone.  back to your regularly scheduled hacking.
21:32:37 <russellb> #endmeeting