21:01:10 <danwent> #startmeeting
21:01:11 <openstack> Meeting started Mon Jun 11 21:01:10 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:20 <gongys> hello
21:01:23 <arosen> hi
21:01:28 <garyk> hi
21:01:28 <danwent> #info http://wiki.openstack.org/Network/Meetings
21:01:29 <ncode> o/
21:01:44 <danwent> wow, big crowd today.  seems like the new time is working out :)
21:01:57 <danwent> #topic folsom-2 deliverable
21:02:30 <danwent> #info folsom-2 branch date is now 3 weeks out… coming up quickly if you consider the review lags we've been dealing with lately
21:02:49 <danwent> #info welcome garyk and gongys as core devs by the way… that should help with review lags :)
21:03:10 * markvoelker applauds
21:03:23 <danwent> #info Our main focus for F-2 work is still getting API v2 fully merged in.
21:03:36 <danwent> #link https://review.openstack.org/#/c/8039/
21:03:59 <danwent> our current plan is to get jkoelker_'s branch merged in, depsite some gaps
21:04:12 <danwent> this will let more people work on top of filling those gaps.
21:04:25 <gongys> Yes
21:04:36 <danwent> I have a branch already stacked on there for API validation and related improvements: https://review.openstack.org/#/c/8366/
21:05:10 <danwent> and gongys has been bravely developing client + CLI code against a not entirely solid spec: https://review.openstack.org/#/c/7596/
21:05:46 <danwent> we're stil keeping the basic wiki page up to date: http://wiki.openstack.org/QuantumV2APIIntro
21:06:16 <danwent> Plan is that all remaining API work should be filed as bugs against F-2:  https://launchpad.net/quantum/+milestone/folsom-2
21:06:28 <danwent> garyk has already volunteered to pick up several of the items, thanks!
21:06:57 <danwent> any questions concerns there?
21:07:37 <danwent> kevin mitchell from rackspace is working on Authz: https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum
21:07:53 <danwent> he seems to have good cycles to work on that, so I'm comfortable with progress there.
21:07:59 <danwent> Is arvind here?
21:08:09 <danwent> markvoelker: ?
21:08:31 <danwent> #info arvind from cisco is working on https://blueprints.launchpad.net/quantum/+spec/quantum-horizon
21:08:48 <danwent> we had a call late last week to scope the first deliverable for F-2.
21:09:09 <danwent> #info horizin on F-2 will focus on basic network creation/deletion, and being able to spin up VMs on a particular network.
21:09:17 <danwent> errr… horizon
21:09:27 <markvoelker> He was around today, but I'm currently at home so can't yell over the cubical wall at him =)
21:09:38 <danwent> markvoelker: that's ok, just yell louder
21:09:51 <danwent> rkukura: any updates on https://blueprints.launchpad.net/quantum/+spec/provider-networks ?
21:10:14 <danwent> rkukura: from emails to the list it seems like you're progressing?
21:10:15 * markvoelker just frightened his 7 month old whilst yelling for Arvin's
21:10:21 <rkukura> yes, specifying vlans works with linuxbridge
21:11:00 <rkukura> Can I get away with ignoring XML until we have proper support for extensibility?
21:11:23 <danwent> rkukura: hrmmm… have we gotten anyone to confirm that there's no good way to do this with XML?
21:11:43 <danwent> I personally have a bias against XML in general...
21:12:03 <danwent> but if we're going to say we support it, it seems odd that we can't do request extensions with it.
21:12:07 <rkukura> I was chatting with Mark McLoughlin about it today
21:12:22 <danwent> was that Salv-orlando running away from an API question? :P
21:12:46 <s0mik> rkukura: Jorge from Rax should be the authority on that
21:13:05 <danwent> s0mik: I agree.  I've tried to loop him into the threads.  We should bug him more.
21:13:12 <rkukura> Seems we need either the template stuff from nova.
21:13:34 <danwent> rkukura: ok, so there's extra code in nova that isn't in quantum that let's them support it in nova?
21:13:57 <rkukura> nova has diverged from the extension framework in quantum/openstack-common/melange
21:14:22 <danwent> ah, how i wish all of this API code was just a openstack-common lib :)
21:14:37 <rkukura> I can write a BP
21:14:39 <s0mik> rkukura: I think the quantum framework was based on nova framework, so hope this becomes common soon
21:14:50 <garyk> openstack-common - the answer to all our problems
21:14:57 <danwent> rkukura: BP for what exactly?
21:15:02 <danwent> garyk:  well, in some cases, yes
21:15:19 <rkukura> According to markmc, nova has gone in a different direction than whats in common
21:15:35 <rkukura> BP for making XML extensible in quantum
21:15:37 <danwent> during the v2 api stuff, I was really saddened by how much code was written that had nothing to do with quantum specifically.
21:16:01 <danwent> rkukura: does common already have API extension framework?
21:16:13 <danwent> last I heard they were just talking about it.
21:16:25 <rkukura> yes, and it looks like quantum's is based on it
21:16:32 <rkukura> but nova has abandoned it
21:17:16 <danwent> rkukura: ok, and there's no way to do request extensions in the openstack-common extension framework either, i assume?
21:17:29 <rkukura> markmc says: "but IMHO, the openstack-common version should just be deleted"
21:17:40 <rkukura> request extensions for json work. xml is the issue
21:17:47 <danwent> rkukura: yes, understood.
21:18:04 <rkukura> the openstack-common version does have some xml support thats missing in quantum
21:18:26 <danwent> Ok, so you think the right think it so do JSON only for now, and port the XML stuff over from nova?  Kind of hurts, as it seems like any porting effort should be done toward getting the stuff working on a common lib.
21:18:42 <danwent> ah, misunderstood you, sorry
21:19:01 <danwent> so if we port over to openstack-common, request extensions can work with XML?
21:19:02 <rkukura> long term we should have a common extension framework
21:19:11 <danwent> rkukura: definitely agree.
21:19:23 <ijw> rkukura: any idea how far nova have diverged?
21:19:39 <rkukura> ijw: significantly
21:19:58 <danwent> Ok, this sounds like a longer conversation.
21:20:03 <rkukura> The nova approach now uses decorators, plus templates for xml
21:20:54 <danwent> so short-term call is whether to (a) use request extension and support JSON only until extension framework changes or (b) implement as resource extension?
21:21:31 <danwent> rkukura: ?
21:21:39 <rkukura> danwent: yes, but still not sure xml would work right with resource extension - optional data seems to be a problem
21:22:16 <rkukura> the nova template approach leaves out the element for missing data
21:22:25 <danwent> Ok, let's take this to the list.
21:22:45 <danwent> rkukura: is this already summarized in an email to the list, or should you write one?
21:23:04 <rkukura> I've been posting as I learn
21:23:07 <danwent> let's be sure to include the main openstack list, as many of the openstack API experts probably aren't on netstack.
21:23:46 <rkukura> I'll summarize the issues/questions
21:23:50 <danwent> rkukura: thanks
21:24:13 <danwent> #todo rkukura send email summarizing decision points around provider networks bp and request extensions with XML
21:24:34 <danwent> ok, now onto the two BPs that concern me the most for F-2 :)
21:24:49 <danwent> #info DHCP BP: https://blueprints.launchpad.net/quantum/+spec/quantum-dhcp
21:24:59 <danwent> carlp: here?
21:25:05 <jkoelker> sorry just catching up, but i agree with mark the openstack-common wsgi stuff should be tossed
21:25:35 <danwent> jkoelker: ok, good to know.  too bad though, as each project seems to be inventing their own wheels :)
21:25:48 <jkoelker> its the way of our people ;)
21:25:51 <danwent> but if its not done right, no point in porting over to it.
21:25:56 <danwent> :)
21:26:39 <danwent> I got an email from mark mcclain at dreamhost saying that they have some internal designs for the dhcp work, but it makes me nervous not to have seen anything yet.
21:27:18 <PotHix> we want to help, but I don't know how yet
21:27:20 <danwent> they say DHCP work in on target for F-2 though, so hopefully that's good news.   I still think we'll probably need people to help out toward the end.
21:27:30 <oubiwann> danwent: he's getting ready to work on this in the next few weeks
21:28:01 <danwent> PotHix: a while back I posted some thoughts on a potential design.  I'd like to see some discussion around designs, that way more people can potentially pitch in and bite off certain pieces.
21:28:17 <oubiwann> danwent: I thought he was waiting on the IPAM stuff to land?
21:28:20 <oubiwann> (mark, that is)
21:28:22 <gongys> I wan to know how the dhcp server will run in quantum? on quantum sever side or agent?
21:28:22 <danwent> oubiwann: thanks.  Just that there's 3 weeks left.
21:28:53 <PotHix> danwent: where can I find your thoughts about it?
21:28:58 <danwent> oubiwann: we have a spec and code that's been in review for a while, so it should definitely be sufficient to make a design.
21:29:05 <PotHix> I just have that e-mails
21:29:39 <danwent> oubiwann: if there's missing info that he's waiting on, please have him raise that immediately.
21:29:41 <PotHix> e-mail*
21:30:47 <danwent> gongys: that's part of why we need some discussion of the design.  I was guessing that there would be agent code that could basicaly query quantum API for IP mac bindings, and "plug" dnsmasq interfaces into virtual switches, similar to what nova-network does today.
21:31:05 <danwent> that at least would be the design that allows us to leverage the most existing code from nova-network.
21:31:33 <danwent> PotHix: yeah, just that email.  I can resend with a wider audience.  Just trying to get the conversation started on this.
21:31:54 <garyk> danwent: can you please send to the list
21:31:56 <danwent> #todo: danwent resent email about simple DHCP design to ML
21:32:38 <danwent> ok, hopefully we can get some more attention focused on DHCP this in the next week.
21:32:39 <PotHix> Cool. I'll send some thoughts.
21:33:11 <danwent> In another bit of bad news, I heard tr3buchet is not going to be able to work on Nova + Quantum integration in F-2: https://blueprints.launchpad.net/quantum/+spec/improved-nova-quantum-integration
21:33:41 <danwent> he has a branch that has a lot of the changes already, though it uses the quantum v1.1 and melange APIs, rather than the quantum v2 API.
21:34:05 <danwent> so we'll need to find someone who can work on this for F-2
21:34:11 <gongys> This bp will rely on IPAM merged in
21:34:36 <danwent> gongys: the new Quantum v2 API merges IPAM into Quantum.
21:34:52 <danwent> gongys: or am I misunderstanding you?
21:35:21 <gongys> dan: no. you are right.
21:35:31 <PotHix> A lot of changes depending on the v2
21:35:36 <PotHix> But itś
21:35:43 <PotHix> But it is almost finished, right?
21:36:17 <danwent> PotHix: agreed, that's why our primary focus needs to be on getting that merged.  Main Api-v2 code should go in today, assuming we get a people to sign off on jkoelker recent tweaks to the branch
21:36:58 <danwent> Ok, so I have a lot of familiarity with the nova + quantum integration, and can help anyone able to work on that.
21:37:33 <danwent> let me know.  this work is very fundemental to being able to see the benefits from the v2 API, so it definitely needs to be done in F-2.
21:37:48 <danwent> Ok, any other F-2 topics?
21:38:10 <garyk> danwent: common config would be nice if it could be reviewed
21:38:11 <danwent> overall, we're getting a lot of great work done, we just have very ambitious goals :)
21:38:22 <danwent> garyk: good point.
21:38:33 <PotHix> danwent: ncode is working on iptables_manager and agents
21:38:48 <danwent> #info: need review love for common-cfg bp: https://review.openstack.org/#/c/8101/
21:38:51 <PotHix> we don't have to include dependencies to it
21:39:12 <danwent> PotHix: is this still the primary review: https://review.openstack.org/#/c/7762/ ?
21:39:20 <danwent> we need to get that in… its been under review for a while.
21:39:31 <gongys> garyk: I think we need put the api v2.0 in first, and then the common config.
21:39:34 <danwent> looks like we're close
21:39:44 <PotHix> danwent: yes
21:39:48 <garyk> ok
21:40:06 <danwent> gongys:  API v2 stuff should really be top priority for everyone, as there are so many dependencies.
21:40:21 <danwent> we all need to pitch in :)
21:40:44 <danwent> #topic community topics
21:41:05 <danwent> oh no, did salvatore drop off?
21:41:38 <danwent> #info wiki page for core devs to sign up for review days: http://wiki.openstack.org/Quantum/ReviewDays
21:42:18 <PotHix> danwent: we're waiting the iptables_manager merge to work on the generic_firewall
21:42:20 <danwent> all core devs should be signed up for a day per week.  double-booking is ok, we'll just expect extra reviewing horsepower those days.
21:42:27 <danwent> PotHix: yes, makes sense.
21:43:08 <danwent> feel free to ping the "active" core devs about reviews on their days.
21:44:19 <danwent> recall that we're expecting 2-3 hours MINIMUM of reviews from a core dev per week.  If you're sticking to the minimum, those hours should be focused on your review day.  You should focus your review energies on the reviews that are most critical to the community (e.g., those blocking a lot of work, or ranked highly on launchpad)
21:45:00 <danwent> as part of my review day, I'll review the reviews to make sure review days are working.
21:45:06 <danwent> :)
21:45:12 <danwent> any questions/comments/concerns?
21:45:47 <danwent> also, feel free to CC on emails you send to the reviewers requesting reviews on their review days.
21:45:52 <danwent> salv-orlando: there you are!
21:46:01 <salv-orlando> here I am!
21:46:05 <danwent> we were just talking about review days
21:46:11 <salv-orlando> I got disconnected
21:46:17 <danwent> "conveniently" :P
21:46:43 <danwent> salv-orlando: anything you'd like to say on review days?
21:47:06 <salv-orlando> I am looking at the wiki page. Slots look pretty full which is great
21:47:41 <salv-orlando> And I see GaryK has volunteered for doing reviews on Sundays :)
21:47:44 <danwent> salv-orlando: yes, though we have a good number of people not signed up yet.  I mentioned that double-booking is ok, we'll have expect even more reviews :)
21:48:04 <garyk> salv-orlando - sunday is a work day and friday is weekend :)
21:48:09 <danwent> salv-orlando: his monday
21:48:23 <danwent> #topic open discussion
21:48:28 <salv-orlando> garyk: I didn't know you were in Israel, sorry :)
21:48:33 <danwent> ok, any other items we need to discuss
21:48:46 <ncode> danwent: I'd like to know about the agents
21:48:58 <danwent> ncode: what about them?
21:49:11 <garyk> ncode: i am working on scalable agents
21:49:14 <ncode> they will use the common from quantum or will get a new one?
21:49:51 <garyk> ncode: the rpc code is taken from openstack comon (if this is your question)
21:49:59 <ncode> is that
21:50:05 <danwent> ncode: current model is that quantum-server and quantum-agents both have access to the same quantum python libraries.
21:50:30 <danwent> that is, there's not a separate common for agents vs. server plugin code.
21:50:31 <ncode> I will move some code to there as gongys said
21:50:54 <danwent> ncode: yes, anything that might be shared across agents should go in quantum/agent/*
21:51:09 <danwent> like the ovs_lib.py example, and the iptables manager code.
21:51:15 <PotHix> danwent: Will we have the same dependencies on agents and server?
21:51:27 <ncode> PotHix: is that my point :D
21:51:38 <ncode> s/is that/that is/
21:52:00 <danwent> PotHix: by dependencies, do you mean package dependencies, like apt-get?
21:52:35 <ncode> more like library danwent, can be package
21:52:43 <danwent> distros can and probably will have different depenedencies for the two, though I agree that our current model does not make it easy for them to determine which is which.
21:53:25 <danwent> ncode:  so you mean like a non-standard python library?
21:54:27 <ncode> danwent: package as you said, but is hard to have some things from quantum server inside XS
21:54:28 <danwent> ncode: we can keep talking about this, but let's wrap up the official meeting.
21:54:33 <ncode> oks
21:54:44 <danwent> anything else urgent that we need to discuss before wrapping up?
21:55:08 <danwent> ok, thanks folks.  stay on the channel if you want to keep talking about agent dependencies
21:55:10 <danwent> #endmeeting