22:01:32 <danwent> #startmeeting
22:01:33 <edgarmagana> hi everybody!
22:01:33 <openstack> Meeting started Tue May 29 22:01:32 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:35 <SumitNaiksatam> Hi All!
22:01:52 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
22:02:20 <danwent> So, F-2 starts today: https://launchpad.net/quantum/+milestone/folsom-2
22:02:57 <danwent> we have a bit of a bottleneck around items that require API v2.0 for F-2
22:03:43 <danwent> jkoelker and team continue to make progress on the branch https://github.com/jkoelker/quantum/commits/melange
22:03:58 <danwent> but I think we're still at least a few days out from a potential merge.
22:04:08 <danwent> jkoelker: around to give a more informed estimate?
22:04:11 <danwent> _cerberus_ ?
22:04:42 <danwent> So to prevent other people from blocking, we're going to work on the detailed API docs
22:05:12 <danwent> gongys: you're probably waiting on the v2 stuff I assume?
22:05:16 <danwent> for https://blueprints.launchpad.net/quantum/+spec/new-cli?
22:05:18 <gongys> yes
22:05:26 <gongys> I am waiting.
22:05:42 <danwent> I think the api stuff is in good enough shape that you can get started.  I will work with you to help you understand the API.
22:06:02 <gongys> ok
22:06:06 <danwent> my guess is that having a client-lib and CLI will be important to have first, as others will need the clientlib to build on.
22:06:29 <danwent> I'm going to work with jkoelker and get at least the most common API flows documented later today/tomorrow.
22:06:50 <danwent> the etherpad is just too messy to make sense of anymore :)
22:07:29 <danwent> the other two BPs that I think we must get done in F-2 are: https://blueprints.launchpad.net/quantum/+spec/improved-nova-quantum-integration
22:07:34 <danwent> (tr3buchet)
22:07:45 <danwent> and https://blueprints.launchpad.net/quantum/+spec/quantum-dhcp (carlp + team)
22:08:20 <danwent> if you're on one of those 4 BPs, I'll be hounding your for updates :)
22:09:09 <danwent> There's lots of other important stuff for F-2, but those have the most dependencies and complexity I believe.
22:09:38 <danwent> Is anything major missing from the F-2 list of BPs?  If so, we should bring it up ASAP, as the release is probably overfull already.
22:10:09 <danwent> I will comment that it would be great to have a few more core devs by the time F-2 is ending, as the reviewing load will be significant given everything that is targeted.
22:10:34 <PotHix> danwent: we'll work with carlp on the dhcp, just waiting for melange merge
22:11:17 <danwent> PotHix: great.  have you already sent him email?  Since there wasn't a concrete design presented on this at the summit, this blueprint is the one that concerns me most for F-2
22:11:51 <PotHix> danwent: yes, but the response was to wait the melange API
22:12:01 <PotHix> so we can decide what to do
22:12:11 <jkoelker> danwent: sorry was working on the tests
22:12:15 <danwent> ok.  once we send out basic docs on the v2 api, we can hopefully put together a design.
22:12:27 <PotHix> cool
22:12:36 <danwent> PotHix: would like to have a sketch by next monday, so i'll try to get you the API docs tomorrow.
22:12:44 <danwent> jkoelker: no worries, probably a better use of your time.
22:13:01 <danwent> jkoelker: was just looking for a general thought on when you might propose that API code.
22:13:22 <jkoelker> hrm, the biggest thing that still needs to be figured out is the ip allocation bits
22:13:29 <PotHix> danwent: cool! Include carlp on the discussion too
22:13:53 <jkoelker> but if peeps don't care about working plugin and just want the APIRouter, then i can do that tomorrow ;)
22:14:01 <danwent> jkoelker: yeah, doing that in a clever way is a bit tricky.
22:14:09 <danwent> haha…
22:14:24 <danwent> probably good to have SOMETHING for IP allocation, though it could be something simple that we later improve on.
22:14:24 <jkoelker> cuz the plugin api is done
22:14:31 <danwent> cool.
22:14:44 <danwent> what is the status of tests?  perhaps that's some place we could pull some more people in on.
22:14:50 <danwent> if anyone can volunteer
22:14:58 <jkoelker> i got everything except for ports working
22:15:08 <danwent> ok, great.
22:15:23 <danwent> so it sounds like we're pretty close.  I'm guessing a couple days and maybe propose by end of week?
22:15:25 <jkoelker> filtering and other methods are all untested
22:15:36 <jkoelker> have yet to run coverage on it to see what needs to be filled in
22:15:40 <danwent> what do you mean by "other methods"
22:15:58 <jkoelker> all the query string stuff
22:16:06 <jkoelker> like show, filter, and verbose
22:16:10 <danwent> ah, ok.
22:16:16 <jkoelker> totally punted on those
22:16:23 <danwent> I'd be fine merging those in separately, if you think that's best.
22:16:24 <jkoelker> just got basic crud tested
22:16:33 <danwent> up to you
22:16:46 <jkoelker> i'm good for whatever
22:17:06 <danwent> I'd rather get the merge at least started soon.
22:17:28 <danwent> that way people can review + get up to speed on the new API at the same time.
22:17:41 <SumitNaiksatam> +1 for phased approach
22:17:50 <gongys> and we will be able to help test
22:18:01 <jkoelker> yea i ahve the github issues to break up the merge
22:18:25 <jkoelker> the biggest question is do ya'll want the v2 api in without the SamplePlugin working?
22:18:33 <jkoelker> if so i can do that like tommorrow
22:18:41 <jkoelker> otherwise its going to be a while
22:18:58 <jkoelker> since we're finding bugs with the implementation when we are writing the tests ;)
22:19:04 <jkoelker> so its a bit of a chicken and the egg
22:19:05 <salv-orlando> jkoelker: which plugin do unit tests for API v2 use?
22:19:19 <danwent> salv-orlando: we created a basic DB/sample plugin
22:19:23 * cdub is surprised SamplePlugin isn't done as part of v2 for testing
22:19:26 <jkoelker> only the V2 sample plugin
22:19:35 <jkoelker> no other plugin is compatible wiht the V2 plugin api
22:19:41 <danwent> cdub: I believe it is...
22:19:54 <jkoelker> cdub
22:19:57 <jkoelker> cdub it is
22:20:00 <jkoelker> that is the question
22:20:10 <jkoelker> do you want to wait on the v2 spec for the sample plugin
22:20:14 <jkoelker> or do you want it now
22:20:15 <danwent> jkoelker: I tend to think we should wait for the unit tests to be running to merge
22:20:45 <jkoelker> well i can fake out a plugin really easy
22:20:53 <danwent> since the only think you can to with the routers alone is look at the code, and we already have access to the branch.
22:21:04 <danwent> ah, you mean write a really simple sample plugin?
22:21:51 <danwent> is that what you mean by "fake out a plugin"?
22:21:54 <jkoelker> no i mean use mock to return the exact data
22:22:31 <danwent> ah, for unit tests only you mean.  I suspect this gets back to the "these unit tests aren't unit tests" comment :P
22:22:37 <jkoelker> ;)
22:22:47 <jkoelker> yea cuz that's the thing
22:22:55 <jkoelker> the v2 api is just a wrapper around getattr
22:23:01 <jkoelker> it really doesn't do much
22:23:05 <danwent> I think there would be value in that, if for no other reason than phasing the merge.
22:23:16 <jkoelker> so if we want tests on just it, then that's easy
22:23:25 <jkoelker> well here's the thing
22:23:44 <jkoelker> i'd rather do one or the other
22:23:51 <jkoelker> because no one will use the sample plugin
22:24:48 <danwent> isn't this what we talked about on the github issue?  That the sample plugin would really be the dbbase_plugin, which others could subclass to implement their plugins?
22:25:06 <jkoelker> yea, but then its totally not my problem ;)
22:25:10 <danwent> haha
22:25:17 <jkoelker> that's the plugin implementor's problem
22:25:20 <jkoelker> ;)
22:26:04 <danwent> I think that's the right long-term direction in that it makes our unit tests more like real unit tests.
22:26:34 <danwent> and separates the testing of the api layer from the testing of the plugin beneath it.
22:26:51 <jkoelker> sweet, any objections?
22:27:05 <danwent> I'm fine with it.
22:27:16 <jkoelker> rock on I'll run with that
22:27:23 <danwent> what is to become of the DB-base code then?
22:27:43 <jkoelker> it will still be there
22:27:47 <danwent> DB-plugin-base?  target for a separate merge with separate unit tests?
22:28:24 <jkoelker> i think whoever uses the ovs-plugin might be able to use it as a base
22:29:07 <danwent> jkoelker: yeah.  I think its worth keeping as a separate class, so that multiple plugins can use it, but I'm ok with it being a separate merge.  We'll have to create some new unit testing infrastructure around it though.
22:29:29 <danwent> but as I said, i think that's a better long term direction.
22:29:39 <jkoelker> excellent
22:29:45 <jkoelker> i'll work on that tomorrow
22:29:49 <danwent> ok, sounds good.
22:30:00 <jkoelker> and see if i can get someone to pull out the authn stuff and submit that
22:30:07 <danwent> ok.
22:30:08 <jkoelker> as well as the db models
22:30:32 <danwent> jkoelker: db models would be separate merge from db-plugin?
22:30:48 <jkoelker> could be
22:31:02 <danwent> i would see them as coupled, but don't feel too strongly.
22:31:05 <jkoelker> some of the cleanup in the db/api is badly needed anyway
22:31:22 <jkoelker> and using declarative_base properly
22:31:49 <danwent> ok, sounds good.
22:32:03 <danwent> ok, so back onto the agenda :)
22:32:16 <danwent> I think we're done with F-2 discussion, so I'll move on to community topics
22:32:22 <danwent> #topic community topics
22:32:45 <danwent> #info we are planning on moving team meetings to monday 2100 UTC starting next week.
22:32:54 <garyk> yay!
22:33:08 <danwent> we are planning on using this same channel, but I need to confirm with Vish that the meeting scheduled in that slot no longer actually meets.
22:33:23 <danwent> vish is on vacation, but will be back soon, so look for a confirmation on the netstack list later this week.
22:34:01 <danwent> #info quantum is participating in the "bug triage day" june 7th:  http://wiki.openstack.org/BugDays/20120607BugTriage and http://wiki.openstack.org/BugTriage
22:34:33 <danwent> #topic open discussion
22:34:51 <danwent> anything?
22:34:58 <gongys> about authn(z) on server side, who is on that?
22:35:01 <danwent> or did jkoelker and I put everyone to sleep :)
22:35:13 <danwent> gongys: that is kevin mitchell from Rackspace
22:35:17 <danwent> jkoelker: do you know his handle?
22:35:29 <danwent> https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum
22:35:40 <SumitNaiksatam> danwent: is there a "work-in-progress" branch for https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat?
22:36:12 <danwent> SumitNaiksatam: not yet… I'm working on it though
22:36:22 <jkoelker> its usually Vek, but he doesn't look like he's on
22:36:23 <SumitNaiksatam> ok
22:36:45 <danwent> jkoelker: there's a branch with some of the authz stuff right, right?
22:37:08 <jkoelker> there is
22:37:15 <jkoelker> it was just updated this morning
22:37:18 <jkoelker> let me get the link
22:37:28 <danwent> this one? https://github.com/jkoelker/quantum/commits/melange-authz
22:37:42 <jkoelker> https://github.com/jkoelker/quantum/tree/melange-authz
22:37:46 <jkoelker> da
22:37:56 <gongys> It is will be in f-2?
22:38:10 <gongys> Will it be in f-2?
22:38:12 <jkoelker> its stacked ontop of the v2 api branch
22:38:36 <garyk> https://blueprints.launchpad.net/quantum/+spec/use-common-cfg - added support for linux bridge and ovs. do we want for the quantum service?
22:38:38 <jkoelker> I have yet to go through it and see what it all does,
22:38:40 <danwent> gongys: it is targeted for f-2 and actively being worked on, so I suspect it will land in f-2
22:38:45 <jkoelker> gongys I think that is the hope
22:38:52 <danwent> garyk: yes please :P
22:39:05 <jkoelker> garyk: yes please
22:39:15 <jkoelker> the quantum/common/config is killing me
22:39:29 <garyk> join the club
22:39:39 <jkoelker> its a party!
22:40:05 <jkoelker> i almost added cfg support for the v2 api
22:40:20 <jkoelker> but then realized the hozer of only the v2 using it
22:40:20 <danwent> ok, great.  any other open discussion?
22:40:21 <garyk> great!
22:40:31 <cdub> garyk: did you see markmc's recent update on that topic?
22:40:43 <gongys> nova will call new quantum api v2.0 in f-2?
22:40:48 <garyk> cdub: yes
22:40:54 <cdub> garyk: cool
22:41:22 <danwent> gongys: yes, that is tr3buchet's work.
22:41:36 <danwent> https://blueprints.launchpad.net/quantum/+spec/improved-nova-quantum-integration
22:42:09 <garyk> is there anyway of nova knowing which plugin is being used?
22:42:12 <danwent> he's had most of it done for a while, waiting on the v2.0 api to finalize before completing it, I believe.  this is the patch I mentioned in the email today, as it will mean you do not need nova-network when using quantum.
22:42:18 <gongys> F-2 will be a big change then.
22:42:43 <danwent> garyk: I would argue that nova shouldn't know.  perhaps it would want to know what type of vif-plugging is supported, but not necessarily what plugin.
22:42:47 <danwent> gongys: yup :)
22:43:02 <danwent> we're trying to get disruptive things in early in the cycle.
22:43:11 <danwent> garyk: what is your use case?
22:43:42 <garyk> danwent: the ovs keeps attachment id's but gw name.
22:43:55 <tr3buchet> danwent: that's exactly right. no sense having to update it over and over
22:44:09 <danwent> garyk: let's chat about this after mtg?
22:44:11 <gongys> Dan: I think  vif-plugging is plugin term on the nova side.
22:44:16 <danwent> or tomorrow if you're tired
22:44:20 <garyk> danwent: great
22:44:38 <danwent> ok, any other issues we need to discuss, or can we let most people go?
22:45:03 <danwent> ok, thanks folks.  keep hacking, see you next week :)
22:45:07 <danwent> #endmeeting