22:03:35 <danwent> #startmeeting
22:03:36 <openstack> Meeting started Tue Feb 14 22:03:35 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:03:53 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
22:04:23 <danwent> #info  E-4 branch point is only one week out:  Feb 21st
22:04:38 <danwent> I'm extremely nervous about how much proposed work there is
22:04:56 <salv-orlando> I am scared by the plugins
22:05:06 <danwent> https://launchpad.net/quantum/+milestone/essex-4
22:05:07 <salv-orlando> they are growing on a daily basis :)
22:05:28 <danwent> salv: yeah.  real concern is that plugin code grows while team of core people who review plugin code does not :(
22:05:59 <GheRivero_> how many plugins can we count now?
22:06:02 <danwent> hopefully we can get more people to join the core team, contributing beyond plugins.
22:06:05 <GheRivero_> 6-7?
22:06:07 <wwkeyboard> Should we try to pull the plugin code out of core?
22:06:08 <salv-orlando> 3 in, 3 in review
22:06:11 <danwent> still just 3 merged.
22:06:17 <salv-orlando> I mean 3 in trunk - 3 under review
22:06:22 <wwkeyboard> and just provide a set of tests that a plugin must conform to?
22:06:24 <GheRivero_> love it :)
22:06:53 <danwent> wwkeyboard:  its definitely possible to not be merged into core and things will run just fine
22:07:22 <danwent> there are several people who do this already, I believe :)
22:07:34 <wwkeyboard> indeed :)
22:07:37 <danwent> at the same time, having plugins in the core repo help people contribute and improve them.
22:07:42 <mandeep> more plugin just indicate wider adoption of quantum
22:07:51 <danwent> mandeep: I agree
22:08:09 <danwent> its definitely my goal to get a healthy set of plugins into the quantum code base
22:08:19 <wwkeyboard> mandeep: +1, but it also puts a burdon on the core quantum code
22:08:20 <danwent> they also serve as examples to future plugin writers
22:08:38 <mandeep> And by design plugin do not destabalize the code base, since they only "exist" if enabled
22:09:16 <danwent> mandeep:  I worry that an argument like that is an argument for a code base with a lot of lightly reviewed, low quality code.
22:09:30 <danwent> we need to make sure plugins are reviewed
22:09:35 <mandeep> Sorry if that was how it spounded
22:09:43 <danwent> mandeep:  no worries :)
22:10:00 <danwent> didn't mean to be critical, only explaining the root of my concerns
22:10:04 <wwkeyboard> Sorry to derail the meeting, maybe this would be better handled on the ML?
22:10:10 <mandeep> I agree that plugins need review, ... just that they allow us to move faster without destabalizing the trunk
22:10:22 <wwkeyboard> We have a lot of points to consider
22:10:32 <danwent> its a balance between getting more plugins to show adoption, and building the core team to support owning the larger codebase
22:10:55 <salv-orlando> Most of the times reviewing is no more harder than read-proofing a document, but it still takes time, especially with larger patches, as reviewers have to figure out what the code does.
22:11:18 <mandeep> I understand
22:11:31 <danwent> wwkeyboard: I'm fine with that.  I don't mean to say that we can't merge all of these plugins, only that the review load will be high, and I want to make sure we don't repeat the mistake of E-3 where were were reviewing code until the last minute, and didn't have enough time to be testing quantum prior to the release.
22:11:41 <danwent> Ok, to the ML
22:12:09 <danwent> I want to make sure we talk about the non-plugin changes for E-4
22:12:15 <danwent> so they aren't overlooked
22:12:22 <danwent> first, salv, v1.1 client changes?
22:12:42 <salv-orlando> Working on them right now
22:12:59 <danwent> salv: btw, I apologize, still have a half written response to your email about client unit tests.
22:13:01 <salv-orlando> I expect to commit code on friday at least for supporting error codes and changes for operational status
22:13:14 <salv-orlando> danwent: no worries.
22:13:15 <danwent> salv: great
22:13:39 <danwent> salv: on unit tests, I suspect that mocking out the server is a fair amount of work, so for the time being I don't see a problem with requiring the server to run client unit tests.
22:13:57 <danwent> you'll always have to worry about the case when the server mock differs from the server anyway.
22:14:02 <salv-orlando> danwent: agreed.
22:14:15 <danwent> ok, let's stick with that for now.
22:14:33 <salv-orlando> I will send an email to the mailing concerning filter specification on the CLI (something that as far as I can see not even python-novaclient does)
22:14:57 <danwent> salv: yeah, quatum's ahead of the game :)  good work salv
22:15:26 <danwent> at some point I'd like to give the client better arg parsing capabilities, similar to what python-novaclient does
22:15:39 <bhall> yes that would be nice
22:15:44 <danwent> but I suspect that this is more work than we have time for in E-4, unless you were already viewing that as a requirement for adding filters
22:16:13 <salv-orlando> agreed but recent feedback (see blogs, twitter) suggest on the client side priority should be given to horizon support
22:16:52 <danwent> interesting… hadn't heard that, but seems reasonable.
22:17:02 <danwent> we'll get to horizon later in the agenda
22:17:12 <danwent> Next topic: ryu controller plugin
22:17:14 <danwent> https://review.openstack.org/3618
22:17:26 <danwent> this poor guy has been sitting in review for weeks now.
22:17:42 <danwent> I will give first round of reviews tonight
22:18:02 <danwent> since this patch breaks code out of openvswitch plugin to a shared dir
22:18:10 <danwent> one point of feedback I wanted to ask the team
22:18:37 <danwent> does it make sense to have one large "common" directory in quantum/plugins, or several more specific "common-X" directories?
22:19:09 <danwent> their patch has an "openvswitch-common" dir I believe, but I was thinking more along the lines of a single common dir, that we tell packages to always include with every plugin.
22:19:29 <somik> I prefer Apache commons style with one large common dir
22:19:35 <mandeep> I agree
22:19:55 <danwent> ok, sounds good.  will give that feedback as part of review.
22:20:22 <danwent> its worth noting that we also have several reviews languishing on gerrit: https://review.openstack.org/#q,status:open+project:openstack/quantum,n,z
22:20:38 <danwent> including some bug fixes from Salv, and a build fix from Monty.
22:21:14 <danwent> if you have time to knock out a few of these, it will clear some pipeline for the rush at the end.
22:21:56 <danwent> NVP plugin:  bhall, is this close to being reviewed?
22:22:18 <bhall> danwent: getting there
22:22:47 <danwent> Ok, by thursday?
22:22:54 <bhall> yeah, sounds likely
22:23:07 <danwent> k, great
22:23:19 <danwent> is debo-os here?
22:24:02 <danwent> does anyone know status of quantum excercise script in devstack?
22:24:24 <danwent> would be nice to have people using that to validate changes when doing E-4 reviews
22:24:55 <danwent> #action #danwent contact #debo-os about progress integrating quantum script into devstack
22:25:22 <danwent> Ok, quantum manager unit tests are still in review in nova: https://review.openstack.org/3858
22:25:37 <danwent> lots of +1s, but we're looking for some final +2 from nova core devs
22:25:54 <danwent> wwkeyboard:  any chance we're going to get melange coverage soon?
22:26:17 <wwkeyboard> danwent: I have no idea whats up with that.
22:26:40 <wwkeyboard> I think jkoelker just added support for melange, but no special devstack tests
22:26:54 <danwent> I think we need to stub out melange like we did for quantum.  currently the code coverage for the melange portion of quantum manager is quite low.
22:27:16 <danwent> wwkeyboard: sorry, I was talking about unit tests in nova
22:27:38 <wwkeyboard> Tests for the melange_ipam_lib?
22:27:44 <danwent> yeah
22:27:55 <jkoelker> wwkeyboard yea melange support is in devstack, still needs some love with configuring ip policies so it doesn't hand out the broadcast
22:28:38 <jkoelker> no excersice scripts yet, kinda waiting to see if we all go, devstack2 or not
22:28:40 <danwent> jkoelker:  maybe create a wiki page with how to enable, or update the Quantum devstack wiki page?
22:29:03 <danwent> http://wiki.openstack.org/QuantumDevstack
22:29:16 <jkoelker> danwent: I'll update the Quantum on, you just put m-svc and melange in your ENABLED_SERVICES
22:29:31 <danwent> sounds simple enough.  thx.
22:30:19 <danwent> ok, is mjfork here?
22:30:41 <mjfork> yes
22:30:48 <danwent> I know nebula folks are hoping to do some quick clean-up of horizon + quantum integration
22:30:56 <danwent> but clock is really ticking on e-4
22:31:05 <danwent> mjfork:  any update on plans?
22:31:17 <danwent> what is state of horizon branch-point/freeze?
22:31:26 <mjfork> i have code here that is shuold be ready for review
22:31:32 <danwent> sweet
22:31:54 <mjfork> I will read up on the gerrit workflow and get it submitted
22:31:58 <danwent> a horizon review, I assume?
22:32:17 <mjfork> yes.  the template used for selecting multiple networks was the edit rules support
22:32:20 <danwent> mjfork:  sure.  feel free to ping netstack list if you have problems with workflow (or the main OS list)
22:33:02 <mjfork> will do. i may work on that a bit later.
22:33:04 <danwent> mjfork:  k, great.  when you push the review, maybe drop a note to netstack list, as most of us won't get email for a horizon review
22:33:32 <mjfork> danwent: ok.
22:33:44 <danwent> An not to side-track things again, but as I mentioned, two new plugin proposals:
22:33:45 <danwent> https://github.com/locaweb/quantum
22:34:03 <danwent> Locaweb contacted me last week.  Still haven't had a chance to look at code in detail though.
22:34:12 <danwent> seems to have a lot of extensions.
22:34:21 <danwent> and is based on OVS.
22:34:35 <danwent> Also, bigswitch: https://answers.launchpad.net/quantum/+question/187700
22:34:47 <salv-orlando> did they sorted the problem they were having with pushing into github? (I'm referring to locaweb)
22:34:51 <danwent> mandeep, is that you, I believe?
22:35:02 <salv-orlando> sorry I meant pushing into gerrit
22:35:22 <mandeep> I am working in the bigswitch plugin
22:35:23 <danwent> salv-orlando: I think they figured it out.  They haven't pushed because I basically told them that I didn't think we'd have time to review it for E-4, so there was no rush
22:35:35 <salv-orlando> danwent: ok
22:35:39 <danwent> mandeep:  good to have you on the team.
22:35:50 <mandeep> danwent: thanks ...
22:36:20 <danwent> ping the netstack list if you need pointers on things.  developer documentation needs some work (please do improve it if you have a chance)
22:36:21 <mandeep> danwent: and now that I am on the project, I am happy to help with other bugfixes/reviews that need resources
22:36:35 <mandeep> danwent: will do
22:36:41 <danwent> mandeep:  that would be great :)  As I said, that's the best way to encourage others to review your code
22:36:56 <mandeep> danwent: ;-)
22:37:06 <danwent> Ok, anything else on E-4?
22:37:33 <danwent> going to be a stickler here, as I don't want another problematic release like e-3 :)
22:38:02 <danwent> ok, last topic before open discussion
22:38:16 <danwent> talked with the PPB earlier today about Quantum becoming a core project
22:39:00 <danwent> people were receptive, but wanted us to first come up with a concrete plan working with people from nova + melange on how quantum woudl interact with those projects moving forward
22:39:47 <danwent> particularly on the nova front, would quantum be replacing nova-network (and if so, when).  Would all network-related functionality like floating IPs, etc. move over the Quantum (and if so, when).
22:40:12 <wwkeyboard> yea and soon? :)
22:40:18 <danwent> I think it is likely that we will be approved (no one objected), but I think it was a good suggestion that we hash these details out first.
22:40:24 <salv-orlando> do you have a deadline for coming back with this plan?
22:40:35 <danwent> next tuesday :)
22:40:49 <danwent> good thing we don't have a bunch of code to write and review between now than then :P
22:41:16 <salv-orlando> lots of things happening next tuesday. Including Napoli playing Chelsea (not that that should bother you on the other side of the Ocean though :))
22:41:17 <danwent> I'm going to talk to jbryce if it seems like we need another week.
22:41:43 <danwent> salv: sounds like you have your priorities right :)
22:41:53 <danwent> ok, any questions about the application?
22:42:13 <danwent> I'm going to ask vishy to help come up with a proposal that we can send out for comments.
22:42:24 <rkukura> Is there still talk of melange becoming part of quantum?
22:42:49 <danwent> I don't think the PPB requires that we have this entirely locked down, but that we at least have a concrete proposal that all parties can agree to.
22:43:03 <danwent> rkukura:  that's the second main question they have.
22:43:41 <danwent> It is possible to run Quantum without Melange (using QuantumManager + Nova IPAM), but I think the goal is to have Melange + Quantum more tightly integrated (perhaps to the point of being the same project, with a shared API)
22:44:01 <danwent> we were hoping to discuss this at the summit, but it sounds like we at least need to put the plan together soon than that.
22:45:11 <danwent> I think it makes sense from a tenant API perspective to have a single API, and hence to track them as largely one project.  Back-end implementations should still be fairly decoupled though, in my opinion.
22:45:34 <danwent> #topic open discussion
22:45:43 <danwent> anyone going to the cloud connect openstack party on wed night?
22:46:19 <danwent> or maybe its that everyone who is going is currently attending cloud connect, and hence isn't at this meeting :)
22:46:27 <danwent> any other open discussion?
22:46:58 <wwkeyboard> I agree they should be more closely tied, the fractures of the data are not along the same lines we have split the services
22:47:16 <danwent> wwkeyboard:  yeah, agreed.
22:47:30 <danwent> ok, thanks folks.  Have a good week, happy hacking (and reviewing!)
22:47:36 <danwent> #endmeeting