21:00:41 <danwent> #startmeeting
21:00:42 <openstack> Meeting started Mon Aug  6 21:00:41 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:53 <danwent> arg… tired today.  too much latenight coding :)
21:01:05 <danwent> #info agenda: http://wiki.openstack.org/Network/Meetings
21:01:15 <notmyname> danwent: latenight coding or http://imgs.xkcd.com/comics/curiosity.png
21:01:43 <danwent> notmyname: surprisingly, i've been so out of it, I didn't even hear about that until about an hour ago :)
21:01:49 <danwent> so, Folsom-3
21:01:53 <danwent> today is the day
21:02:08 <garyk> hi all
21:02:09 <danwent> all reviews for features (i.e., anything with a blueprint) should be in today
21:02:20 <danwent> these reviews can be WIP reviews
21:02:34 <danwent> but we at least need to see where things are, and identify big problems early
21:02:48 <danwent> code freeze is one week from tomorrow
21:02:49 <garyk> danwent, http://www.gocomics.com/nonsequitur/2012/08/03
21:03:07 <SumitNaiksatam> Hi All!
21:03:12 <danwent> :)  frighteningly familar :)
21:03:17 <danwent> familiar
21:03:33 <arosen> hi
21:03:53 <danwent> anyone with a blueprint for Folsom-3 that does not expect to have a WIP posted today?
21:04:15 <edgarmagana> danwent: even code enhancements should go in today?
21:04:43 <danwent> anything that is either a key deliverable in the release, or has impact on other chunks of code.
21:04:47 <nati_ueno> Hows's this https://blueprints.launchpad.net/quantum/+spec/expose-dhcp-server-ip ?
21:04:55 <danwent> edgarmagana: are you talking about the item that is specific to cisco plugin?
21:05:19 <danwent> I suppose if its impact is scoped to the plugin, that's up to you.
21:05:29 <edgarmagana> danwent: ah ok.. I have time then! This does not impact anything
21:05:30 <danwent> but remember that reviewer load will be very heavy early next week.
21:05:38 <markmcclain> danwent: It's likely that the DHCP+RPC WIP won't be posted until the morning
21:05:45 <edgarmagana> danwent: Yes, I am
21:05:55 <danwent> markmcclain: ok, good to know.
21:06:34 <danwent> yes, RPC stuff is one of the things I'm expecting to drag out a bit.
21:06:42 <salv-orlando> nvp-v2-plugin is also scheduled to come late night (although maybe it WIP-able right now)
21:06:46 <garyk> markmcclain, you based on https://review.openstack.org/#/c/9591/
21:07:16 <markmcclain> garyk: yes and also the OVS one too
21:07:18 <nati_ueno> If no one do expose-dhcp-server-ip, I can submit it today
21:07:22 <danwent> ok, so other than RPC stuff for both DHCP + my L3 branch, I think we're mostly on target.
21:07:36 <garyk> markmcclain, cool
21:07:40 <danwent> nati_ueno: ok, sounds good.
21:07:55 <danwent> nati_ueno: that one is small enough (I hope) that even if you waited another day or two, I think you would be ok.
21:08:10 <danwent> not to encourage you to delay or anything… :P
21:08:23 <nati_ueno> danwent: OK I got it. Could you assign the bp for me?
21:08:39 <danwent> nati_ueno: done
21:08:44 <nati_ueno> danwent: Thanks
21:09:02 <danwent> oh, the one other item is v1 removal
21:09:25 <danwent> i think i'll whip up something quick on that tonight, so people can at least see what is coming down the pipe.
21:10:05 <carlp> I have one issue I found, and I'm not sure if it's already covered.  If you have overlapping IP ranges, then the metadata server does not work. I have some thoughts on how to fix this, but I wanted to see if anyone else had any work/plans on this...
21:10:10 <garyk> danwent, i can help with the v1 if you want
21:10:17 <danwent> ok, so other than having gobs of code to review in the next week, sounds like things are moving forward.
21:10:42 <danwent> garyk: already have some of it local.  if I don't get to it tonight, will let you know
21:10:51 <garyk> dansmith, ok
21:10:55 <danwent> carlp: i was dealing with that over the weekend too.
21:11:24 <danwent> carlp: want to create an item to track work on that and to discuss possible designs?
21:11:32 <carlp> danwent: yes
21:11:37 <garyk> danwent, carlp , can you guys please elaborate on the problems
21:11:46 <rkukura> danwent: Will there be much file renaming (i.e. removing v2 from filenames)?
21:11:49 <danwent> i have a feeling there are a few issues lurking in the nova + quantum v2 integration that we have yet to fully iron out.
21:12:07 <danwent> rkukura: I was not planning on removing v2 from file names… i figured there's no need to introduce churn
21:12:18 <rkukura> danwent: agreed
21:12:33 <danwent> garyk: nova's metadata server uses the source IP of a metadata request to map to a particular instance.
21:12:42 <carlp> garyk: Sure.  When using the new IPAM stuff, you can have multiple networks with the same IP address ranges.  When that happens, the metadata server (which only goes by the IP of the VM) can't figure out what to do
21:13:00 <carlp> in our implementation, everyone has the same private IP space by default
21:13:01 <garyk> danwent, carlp tx
21:13:18 <danwent> carlp: can you create a lp issue and assign it to F-3?
21:13:25 <salv-orlando> danwent: It is probably just me not being able to do a proper search on launchpad, but it seems we also need to track the issue concerning having nova security groups work with Quantum (mostly for the dhcp_server bit)
21:13:29 <carlp> danwent: on it
21:13:34 <danwent> we at least want to keep it on our radar for F-3, even if we can't do anything in that time frame
21:13:59 <danwent> salv-orlando: that was the motivation for the BP that nati_ueno just took, right?
21:14:01 <danwent> or was there more?
21:14:14 <danwent> https://blueprints.launchpad.net/quantum/+spec/expose-dhcp-server-ip
21:14:40 <danwent> though there's extra nova work as well to grap that IP and put it in the network object
21:14:40 <salv-orlando> ok so I was looking in the wrong place.. bugs - I should have been looking in bps
21:15:44 <danwent> ok, anything else before we move on to key reviews?
21:16:18 <danwent> One thing to note: given the extremely heavy review load at the end of F-3, remember to prioritize reviews based on the priority of the associated bp/bug in launchpad
21:16:41 <danwent> ok, first review to cover
21:16:43 <danwent> https://review.openstack.org/#/c/9591/
21:16:49 <danwent> garyk's rpc branch
21:16:55 <garyk> yay
21:17:02 <danwent> this has been pretty picked over, garyk, is this good to go in your opinion?
21:17:12 <danwent> any outstanding issues?
21:17:22 <danwent> also, there's a devstack review for that branch: https://review.openstack.org/#/c/10489/
21:17:31 <danwent> garyk, which should be merged first?
21:17:38 <garyk> correct. linux bridge is ready to go. ovs needs a little work
21:17:45 <garyk> devstack first
21:17:59 <danwent> ok… i'll ping dean once I've +2'd the devstack review.
21:18:06 <garyk> gracias
21:18:13 <danwent> salv-orlando: https://review.openstack.org/#/c/9845/  public networks.
21:18:29 <salv-orlando> comments addressed. just pushed another patch for review.
21:18:45 <garyk> i had a problem with this one - maybe my misunderstanding. was only able to create private networks
21:18:47 <danwent> ok, do we have two cores working on reviewing the patch already
21:18:47 <danwent> ?
21:19:07 <salv-orlando> garyk: I was writing you an email.
21:19:20 <garyk> salv-orlando: great. if it is my bad you have +2
21:19:23 <salv-orlando> however, bottom line is that you can create network with permission 0644 only if you're admin
21:19:38 <salv-orlando> unless you remove the appropriate line from policy.json
21:19:52 <garyk> tx, i'll give it a bash
21:20:05 <danwent> ok.  i will try and be the second core on that one
21:20:35 <danwent> I also wanted to call attention to the quantum + horizon review: https://review.openstack.org/#/c/10116/
21:20:46 <amotoki> hi
21:20:55 <danwent> would be good to get some reviewers/testers from quantum to look at this.
21:21:10 <danwent> amotoki: anything to report on this?  looks like unit tests for horizon where having issues?
21:21:26 <amotoki> Almos all features have been implemented.
21:21:55 <amotoki> I informed Gabriel that it is ready for review just before the meeting. I will also send an email after the meeting.
21:22:15 <danwent> amotoki: great.  i'm guessing gabriel will want to have unit tests working before a review though
21:22:25 <danwent> do you know why they are failing in jenkins?
21:22:32 <amotoki> regarding unit test, jenkins uses the released version of quantumclient.
21:22:46 <amotoki> it seems be the reason jenkins fails.
21:23:01 <amotoki> I will talk with Gabriel about that.
21:23:05 <carlp> danwent: https://blueprints.launchpad.net/quantum/+spec/metadata-overlapping-networks
21:23:18 <danwent> ah, ok.  please include monty + james blair on those dicussions, as me as well.
21:23:22 <danwent> carlp: thanks.
21:23:38 <danwent> monty and james manage the jenkins infrastructure.
21:23:49 <jeblair> hi!
21:24:00 <amotoki> I also saw the thread on ML about glanceclient.
21:24:29 <danwent> jeblair: hi, does jenkins run horizon unit tests with trunk versions of other clients, or a past release version?
21:24:50 <danwent> we need it to run with the latest of our client, since only that version has v2 API support.
21:24:56 <salv-orlando> didn't we had the same issue with nova when we did the quantum v2 integration?
21:25:04 <jeblair> the unit tests run in a virtualenv with the versions of other software as specified in pip requires
21:25:32 <jeblair> danwent: so the solution is probably to make sure that the versions you need are released, and then specify those versions in pip-requires
21:26:02 <jeblair> (it should be easier for client libs to release now, the ptls just need to tag them.)
21:27:02 <danwent> jeblair: yes, though i'm a bit anxious about doing a release until the stuff has had more testing...
21:27:18 <jeblair> danwent: which client?
21:27:25 <danwent> python-quantumclient
21:27:41 <danwent> ok, we can take this offline.
21:28:02 <danwent> but come to think of it, i'm not sure why the horizon unit tests necessarily even require the client library
21:28:17 <danwent> ah, forget it, probably imports.
21:28:45 <danwent> amotoki: ok, let's work with gabriel to get to the bottom of these unit test issues asap
21:28:54 <danwent> please send mail out to all of us.
21:28:57 <amotoki> anyway i wil check the error reports after the meeting.
21:29:08 <jeblair> danwent: sounds good.
21:29:34 <danwent> ok, next review
21:29:35 <danwent> https://review.openstack.org/#/c/10828/
21:29:35 <amotoki> i wil send the status update to related peoples.
21:29:50 <danwent> nati_ueno: this is devstack exercise script for quantum with v2 support
21:29:56 <nati_ueno> Yes
21:30:08 <nati_ueno> It is testing very simple test case now.
21:30:13 <danwent> this is critical to getting quantum to be part of the commit gating
21:30:52 <danwent> nati_ueno: we also need to work with markmcclain, as once the dhcp namespaces stuff goes in, this will cause issues, right?
21:31:11 <danwent> as the test host will no longer have an IP to ping the network directly?
21:31:13 <nati_ueno> danwent: Yes it true. After that one is merged, I'll update devstack
21:31:32 <garyk> danwent: namespaces may be problmatic with different linux flavors
21:31:40 <danwent> ok.  markmcclain's patch is pretty small, so we should be able to merge it soon,  would be good to have devstack change ready.
21:31:42 <markmcclain> danwent: yes we'll have to update the code to properly cleanup namespaces when someone unstacks
21:31:53 <danwent> markmcclain: agreed
21:32:10 <danwent> garyk: what kernels will have problems?
21:32:18 <danwent> namespaces have been around for a while, right?
21:32:28 <danwent> or is it not a kernel issue?
21:32:29 <garyk> i had problems with ubuntu 11. have yet to try fedora 17
21:32:46 <nati_ueno> ubuntu11 not support namespace
21:32:48 <garyk> mark can maybe add some more info
21:33:28 <garyk> is this a limitation that we can live with?
21:33:32 <danwent> is it that they did not support namespaces, or that namespace where configured using a different utility?
21:33:48 <danwent> namespaces have been around since 2.6.27
21:33:53 <danwent> according to google
21:33:57 <markmcclain> ubuntu 11 does not "ip netns"
21:34:12 <danwent> yeah, that was my guess...
21:34:16 <markmcclain> the kernel itself doesn't support it
21:34:38 <danwent> oh really? what kernel is ubuntu 11?  or is it just that it wasn't enabled?
21:34:45 <salv-orlando> the latter I believe
21:34:52 <rkukura> I think the version of iproute2 in RHEL and maybe other distros doesn't support netns
21:34:55 <nati_ueno> Ah it support namespace but it is different spec for ubuntu11
21:34:57 <salv-orlando> the vanilla kernel is compiled without support for netns
21:35:56 <garyk> i think that this is certainly something that we should consider for deployments and usage
21:36:15 <amotoki> Until Folsom release, we need to clarify which kernel version supports namespace.
21:36:35 <markmcclain> yeah… I was wondering what our minimum supported versions
21:36:48 <danwent> yes, though it seems like the tricky thing is not saying what kernel version, so much as what distros have namespaces enabled
21:36:50 <markmcclain> Nova says 12.04+ and f16+
21:37:14 <danwent> garyk: can you check out the status of namespaces on fedora?
21:37:21 <markmcclain> f17 has them
21:37:21 <danwent> (as a TODO)
21:37:26 <garyk> danwent: ok
21:37:38 <markmcclain> I've testing with based on garyk's feedback
21:37:49 <danwent> anyway, at this point, for Folsom I don't see many alternatives to using namespaces.
21:38:15 <danwent> does anyone see alternatives?
21:38:28 <salv-orlando> nothing that can be ready for folsom
21:38:48 <garyk> markmcclain: i am using f16 not 17
21:39:00 <salv-orlando> I think we can already make them optional, scarfing the ability of having overlapping cidr, is that right?
21:39:20 <salv-orlando> I meant "sacrificing" not "scarfing"
21:39:34 <danwent> it would be possible to run a dhcp + l3 agent that is dedicated to a single router
21:39:51 <danwent> and you could run this in an isolated VM if you really had to (the one vm per tenant model)
21:40:04 <danwent> but other than that, I can't see many options of avoiding namespaces
21:40:14 <salv-orlando> danwent: agreed. But do you see this feasible for folsom?
21:40:35 <danwent> salv-orlando: you mean making the agents support just taking care of a single router?
21:41:05 <salv-orlando> I mean running the agents in a separate VMs. We will need to take care of the life cycle of these vms
21:41:11 <danwent> for the l3-agent its pretty simple, and I'm guessing it wouldn't be a major change for the dhcp stuff, but its more work at a time when we already have plenty to do :)
21:41:14 <salv-orlando> and also prepare an image
21:41:25 <danwent> salv-orlando: ah, wasn't talking about managing vm life-cycle
21:41:50 <danwent> just modifying the agents so that someone could use them in such a use case if they where managing vm life-cycle themselves.
21:42:33 <danwent> #todo: #garyk #danwent define minimum distro version requirements for overlapping IPs
21:42:37 <salv-orlando> I see your point. Maybe we can move it to the mailing list. Shouldn't be an issue once RPC is in place.
21:43:05 <danwent> markmcclain: how hard it is to have a version of the dhcp stuff that doesn't use namespaces… from what I remember in the code, should be relatively straightfoward?
21:43:22 <markmcclain> danwent: it's easy to make it configurable
21:43:37 <markmcclain> it's really dependent on the interface driver in use
21:43:41 <danwent> ok… so good that we identified this as an issue.  Let's move it to the ML
21:43:56 <danwent> markmcclain: mmm…. not sure I follow, but we can talk more on ML
21:44:30 <danwent> damn, we're still in the reviews section of the agenda
21:44:41 <danwent> ok, any other important community reviews that anyone needs to call out?
21:44:50 <danwent> 3…2…1.
21:45:03 <salv-orlando> Yeah this meeting it's going to last till dawn for me and garyk :)
21:45:07 <danwent> :)
21:45:11 <danwent> ok, XML support
21:45:21 <salv-orlando> I'm reviewing andrews' patch
21:45:23 <danwent> (we're on to design issues section)
21:45:32 <salv-orlando> But I will commit the review in the morning...
21:45:39 <danwent> nati_ueno: did you say that vishy is planning on dropping XML support from nova?
21:45:48 <danwent> if so, i'd move to drop XML support from quantum
21:45:54 <nati_ueno> danwent: Yes We discuss it in nova meeting.
21:46:32 <danwent> even if we get this patch merged, i still think there's a lot of overhead dealing with XML, and we have the issue that XML can't communicate the notion of null/None
21:46:39 <danwent> what do others thing on this topic?
21:47:07 <rkukura> I was curious if/how extended attributes would be supported, but haven't had time to look
21:47:16 <salv-orlando> I think that as we're introducing a new version of the API, which is not bw-compatible
21:47:23 <salv-orlando> this is the time to make a decision
21:47:38 <danwent> salv-orlando: agreed.
21:47:42 <salv-orlando> if we vote for xml support now, we'll have to maintain it at least until Qauntum v3 is released
21:48:05 <salv-orlando> extended attributes might be supported with xml namespaces, but some work is perhaps required on the patch
21:48:22 <danwent> ok, so i'm not hearing any strong input, so how about i'll rephrase.  Is anyone against eliminating XML support, as long as nova does not support XML either.
21:48:25 <salv-orlando> I think null values might be supported through empty elements, but still need to check for feasibility
21:48:46 <danwent> salv-orlando: my question there was how to tell the difference between empty string and Null
21:48:53 <gongys> Is it XML mandatory? If not, defer it.
21:48:59 <jkoelker> +1 for dropping xml, I don't recal the exact percentage, but it was a small percentage of our traffic is xml
21:49:02 <salv-orlando> I'd like to hear about this from people who put Quantum in production
21:49:24 <jkoelker> we use json exclusively for quantum communication
21:49:26 <salv-orlando> jkoelker must have read my mind
21:49:47 <danwent> ok, so i'll plan on removal
21:49:51 <danwent> i'll confirm with ttx
21:49:51 <nati_ueno> FYI nova discussion about xml it start from about 21:16:05 http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-17.00.log.html
21:49:52 * _cerberus_ hugs danwent
21:50:04 <danwent> nati_ueno: great, thanks
21:50:08 <danwent> _cerberus_: now that's a first :P
21:50:18 <_cerberus_> You're right, usually I'm more suggestive
21:50:43 <danwent> ok, nati_ueno, so assuming we remove XML, then for the gateway_ip issue you wanted to discuss, can we just use json null?
21:50:46 <salv-orlando> <note xml="adios"><bye></bye></note>
21:51:06 <nati_ueno> danwent: Sorry removing XML is not decided yet. But nova guys are going to propose it as the log
21:51:06 <danwent> gongys: is there a way to pass in null values in the CLI?
21:51:22 <nati_ueno> danwent: I agree for just use json null
21:51:58 <danwent> ok, i'll follow up with gongys later
21:52:03 <danwent> Next topic, to keep things moving
21:52:14 <danwent> extensions that introduce new resources
21:52:38 <danwent> SumitNaiksatam, gongys, and I all have the same need, which is to have an extension that introduces a new resource
21:52:40 <salv-orlando> on previous topic (null values), nati_ueno started a thread on the ml. Please share your thoughts there
21:52:49 <gongys> My quota is using this.
21:53:00 <gongys> introduce new resouce in ext.
21:53:05 <danwent> gongys: yes
21:53:07 <nati_ueno> Metaplugin will add flavor resource in ext
21:53:11 <salv-orlando> why the existing framework is not good enough?
21:53:44 <garyk> one thing is lacking - in some cases extensions are valid to all plugins - for example quotas
21:53:51 <danwent> salv-orlando: there's no way to introduce a new resource that automatically takes advantage of all of the resouce-goodness from jkoelker's API framework.
21:54:34 <salv-orlando> Ok, so I suspected this. Basically the issue is that currently extensions kind of live in a world of their own.
21:54:38 <danwent> in my l3 patch, I took an approach similar to what rkukura did for attributes, where the main API code asks each extension whether there are any new resources it wants to introduce.
21:55:05 <salv-orlando> danwent: you're not using anymore an extension middleware?
21:55:09 <danwent> salv-orlando: yes, so you can continue to have them in their own world, but then they don't take advantage of validation, policy, generic code, etc.
21:55:14 <danwent> salv-orlando: correct
21:55:36 <danwent> anyway, I will have a WIP up by tonight, but this is something we need to agree on a single approach for doing and tackle
21:55:46 <gongys> NO, in quota ext, I am using the generic validation code.
21:55:46 <jkoelker> there is nothing to say they could not use their own mapper and then use it all
21:55:47 <salv-orlando> danwent: agreed.
21:56:42 <gongys> We just need to use the same prepare_body_xx() (I forget the function name) function as base code does.
21:56:49 <danwent> gongys: ok, I will take a look.  My main motivation was not actually around validation, so perhaps there's a way to leverage that some other way.
21:56:55 <danwent> gongys: agreed.
21:57:26 <salv-orlando> I think we can make the code base a whole lot leaner if we just map extensions with the same criteria we use for base resources.
21:57:33 <rkukura> danwent: I like the approach you were suggesting
21:57:39 <salv-orlando> We just need a slightly different approach for loading extensions.
21:57:55 <danwent> salv-orlando: that is how i'm leaning as well.
21:58:12 <danwent> ok, so if someone wants to drive this, let me know.  otherwise, i'll slice off the related code from my patch, and propose it.
21:58:37 <salv-orlando> I would love to lead, but I will be offline wednesday and part of thursday this week.
21:58:41 <danwent> ok, we have one more design topic, but we're at the end of our time.
21:58:47 <gongys> I have reexamined the whole extension framework in nova project. After removing v1 code, I want to refactor the quantum extension framework
21:59:05 <danwent> so I'll quickly open it up for open discussion, then anyone who wants to discussion multi-host dhcp can stick around after.
21:59:23 <rkukura> gongys: that sounds like a good summit session to me
21:59:33 <danwent> gongys:  for folsom, or later?  I don't think we have time for anything significant in folsom
21:59:34 <salv-orlando> I have a quick comment on the failing tests for horizon: #from .tables import DetailsTable
21:59:35 <salv-orlando> 38	from .subnets.tables import SubnetsTable
21:59:36 <salv-orlando> 39	#from .subnets.views import CreateView as AddSubnetView
21:59:37 <salv-orlando> 40	from .ports.tables import PortsTable
21:59:44 <danwent> #topic open discussion
21:59:50 <salv-orlando> sorry did not meant to press enter before open discussion :)
22:00:00 <salv-orlando> seems line 40 should be commented out
22:00:10 <danwent> ok, any other open discussion?
22:00:26 <gongys> flaoting ips for nova integration?
22:00:26 <amotoki> salv-orlando: thanks. i'll check it.
22:00:29 <danwent> also remember to sign up for a review day if you haven't already: http://wiki.openstack.org/Quantum/ReviewDays
22:00:50 <nati_ueno> Can we discuss about multi-host?
22:01:00 <danwent> gongys: there's a bug for that in F-3.  will have proposed new floating-ip calls up in WIP branch tonight
22:01:07 <danwent> so we can start working on it as soon as tomorrow.
22:01:15 <danwent> nati_ueno: yup, just after open discussion
22:01:21 <gongys> ok
22:01:26 <danwent> gongys: did you want to work on that?
22:01:29 <nati_ueno> danwent: I got it
22:01:31 <danwent> I can point you to the bugs
22:01:51 <danwent> gongys: #1023169
22:01:58 <danwent> #1031119
22:02:03 <gongys> two?
22:02:26 <danwent> one is for reporting floating ips in commands like nova list
22:02:34 <danwent> other is for proxying nova floating ip calls to quantum
22:02:48 <danwent> ok, let's wrap this up.  otherws are welcome to stay for multi-host discussion
22:03:04 <danwent> thanks folks, have a good week, please remember to spend a lot of cycles reviewing this week.  its crunch time :)
22:03:08 <danwent> #endmeeting