21:00:11 <danwent> #startmeeting
21:00:12 <openstack> Meeting started Mon Aug 13 21:00:11 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:20 <edgarmagana> hello all
21:00:22 <danwent> ok, lots to do, not time to waste
21:00:44 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:00:52 <danwent> a coupel of announcments
21:01:08 <rkukura> hi
21:01:11 <shivh> hi
21:01:11 <danwent> #info Quantum support in horizon merged last night.  Huge achievement, great work folks.
21:01:30 <mestery> Yay!
21:01:31 <danwent> #info we're about to release a version of the python-quantum library that is compatible with API v2
21:01:47 <ncode> hi
21:01:47 <garyk> hi
21:02:02 <danwent> #info python-quantumclient version will be "2.0" as well, and we can rerelease as needed, it is not tied to main openstack milestones
21:02:04 <danwent> hi folks
21:02:12 <danwent> Ok, now on to Folsom-3
21:02:16 <danwent> #topic folsom-3
21:02:25 <danwent> #link https://launchpad.net/quantum/+milestone/folsom-3
21:02:38 <danwent> first off, I'd like to thank everyone who put some extreme hours of work in over the weekend
21:02:46 <gongys> hi
21:03:09 <danwent> we're in a lot better shape going into this week than I would have expected. .. lot's of late night reviews + coding. so great work everyone.
21:03:26 <danwent> All F-3 features need to be merged by end-of-day on Tuesday
21:03:30 <danwent> that will be pacific time
21:03:36 <rkukura> midnight?
21:03:50 <danwent> rkukura: if you want to be up at midnight pacific time, i'll be up to approve :)
21:04:06 <danwent> rkukura: realistically, its when ttx wakes up in europe the next day, but yeah, let's say midnight
21:04:07 <gongys> that is my midday.
21:04:28 <salv-orlando> I can fly to Paris and take tax out for the night tomorrow
21:04:31 <salv-orlando> ttx
21:04:40 <danwent> salv-orlando: haha
21:04:48 <zhuadl> hello
21:04:57 <danwent> if you're no longer coding or reviewing for F-3, please shift your focus to testing
21:05:23 <danwent> the set of feature freeze exceptions for items that don't land by tuesday midnight will be very limited.
21:05:49 <danwent> its not just a matter of whether your code is disruptive, its also a matter of taking developer and reviewer time away from bug fixing, writing docs, etc.
21:06:05 <danwent> ok, so any general questions on F-3 before we go into specific reviews?
21:06:23 <danwent> first up: rkukura, provider networks
21:06:37 <danwent> https://review.openstack.org/#/c/10938/ is for LB, which we think is about ready to merge
21:06:45 <danwent> a second branch with OVS support is due tomorrow?
21:06:54 <rkukura> yes, working on that now
21:07:08 <rkukura> getting phase 2 in today would really help
21:07:09 <danwent> ok… i'm mentally marking that as one that may go down to the wire.
21:07:29 <danwent> rkukura: I think we'll be able to.  was too busy creating meeting agenda to review it after my doctor's appt
21:07:41 <rkukura> ok
21:07:43 <danwent> next up: L3 + Floating Ips
21:07:51 <edgarmagana> rkukura: do you need the LB merged first?
21:07:51 <danwent> this is fully functional and up for review
21:08:09 <danwent> but is still in WIP, since we're missing unit tests for the agent, and for the CLI.
21:08:29 <danwent> i'm hoping to get those unit tests in place by tomorrow morning, but we should be able to do a review of the rest of the code already.
21:08:42 <danwent> arosen and mnewby own that review
21:08:54 <danwent> I've also sliced off a very simple test review that anyone coudl do: https://review.openstack.org/#/c/11259/
21:08:55 <rkukura> edgarmagana: a lot of LB is getting cloned into OVS, so getting issues resolved now is key. Also, the constant rebasing is killing me.
21:09:35 <danwent> a note on the L3 + floating ips: non-polling won't make it for F-3.  its something we can consider for a ffe
21:09:45 <danwent> is simon here to talk about his branch?
21:10:05 <danwent> work to implement host-routes + dnsnameservers in db-base-plugin
21:10:06 <danwent> https://review.openstack.org/#/c/10791/
21:10:19 <danwent> salv, aaron, i think this is basically ready to be approved.  He just needed to rebase?
21:10:28 <salv-orlando> yes
21:10:36 <danwent> ok, let's get that in asap
21:10:52 <danwent> markmcclain: https://review.openstack.org/#/c/10997/  dhcp non-polling
21:11:00 <danwent> looks like garyk is ok with this branch
21:11:19 <danwent> (or at least a previous version of it)
21:11:19 <SumitNaiksatam> I am also looking at it
21:11:27 <garyk> danwent: yes. just have a few more files to review. it is looking good
21:11:29 <danwent> SumitNaiksatam: yup, thanks.
21:11:43 <markmcclain> cool.. the constant rebasing has been killing me too
21:11:47 <danwent> ok… so i'm optimistic that we'll get that in by later today.
21:11:51 <SumitNaiksatam> should have the review in a bit
21:11:54 <danwent> yeah, rebase hell is pretty much universal here.
21:12:18 <danwent> gongys: https://review.openstack.org/#/c/10484/
21:12:25 <danwent> per-tenant API quotas.
21:12:42 <danwent> gongys: let's chat after the main irc meeting to sort out the design issue we've been discussin in the review
21:12:48 <gongys> ok
21:13:08 <danwent> nati_uen_:  https://review.openstack.org/#/q/topic:bp/test-agent,n,z
21:13:17 <nati_uen_> Hi
21:13:21 <danwent> this is somewhat new, but its related to our devstack gating, which is very important
21:14:00 <danwent> basically, we need some smarter logic for devstack exercise scripts to be able to ping VMs now that we use namespaces (though I guess we could also just have devstack disable namespaces, now that arosen's patch landed)
21:14:14 <danwent> here are both patches: https://review.openstack.org/#/q/topic:bp/test-agent,n,z
21:14:47 <danwent> once we get our F-3 features in, it will be very important for us to get devstack gating working, as its a requirement for us to be a "core" project in Folsom
21:15:16 <danwent> nati_uen_: if we don't get the test-agent in by tuesday, I think we could ffe it.
21:15:33 <danwent> multi-host dhcp:  this one causes me more concern: https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
21:15:42 <nati_uen_> danwent: OK I got it
21:15:45 <danwent> seems like design is still up in the air.  unlikely to land for F-3
21:16:10 <danwent> this is pretty important though, and is applicable across a wide number of people, so I'd consider an ffe for it.
21:16:20 <nati_uen_> danwent: I think we agreed the design
21:16:39 <garyk> what is ffe?
21:16:48 <danwent> nati_uen_: on paper, yes :)  always a slightly different thing to see if both people where thinking about the same design when it becomes code
21:16:48 <nati_uen_> danwent: So at least we can request review until Thursday
21:16:55 <danwent> garyk: sorry, "feature freeze exception"
21:16:57 <danwent> ffe
21:17:01 <nati_uen_> danwent: I agree
21:17:02 <garyk> danwent: thanks
21:17:13 <danwent> defines what other than a pure bugfix can go in after tuesday night
21:17:32 <danwent> general criteria are 1) risk of disruption 2) value to the community
21:18:20 <danwent> ok, those are all of the community critical reviews I was tracking
21:18:42 <danwent> there are some other items under review… if they are important to you, please get core devs to be aware and review thme.
21:18:52 <danwent> nati_uen_: we'll talk about device_owner stuff below
21:18:56 <danwent> anything missing?
21:19:10 <danwent> we'll talk about xml and rootwrap in the discussion section
21:19:14 <nati_uen_> danwent: Host route fixing should be in F
21:19:35 <danwent> nati_uen_: are you talking about simon's patch? or something beyond that?
21:19:46 <danwent> btw, is there a bug tracking making dhcp inject those values?
21:19:54 <danwent> that is something we'll have to look at for an ffe.
21:19:54 <nati_uen_> danwent: Yes it is
21:20:06 <nati_uen_> danwent: My point is dhcp injection.
21:20:07 <danwent> nati_uen_:  ok, yes, we discussed it above then.
21:20:39 <danwent> nati_uen_: yes, we'll probably have to do an ffe for that, unless you think you can whip it up very quickly.
21:20:44 <nati_uen_> danwent: OK. And also simon's patch only deal with subnet model. So I'll work on port model
21:20:57 <danwent> nati_uen_: ok.
21:21:03 <nati_uen_> danwent: OK I'll request review in Today's night
21:21:12 <danwent> hehe, ok
21:21:23 <nati_ueno> :)
21:21:23 <danwent> #topic developer discussion
21:21:32 <danwent> ok, we have a couple topics to cover
21:21:37 <danwent> the first is XML support in the API
21:21:52 <danwent> i'm guessing most of you saw the "spirited" discussion on the ML for nova's XML support
21:22:10 <danwent> right now, quantum is JSON only.
21:22:13 <zhuadl> yes :-)
21:22:25 <danwent> we have a patch that adds at least some XML support
21:22:33 <danwent> but I'm not sure we want to go down that route
21:22:46 <danwent> my preference is to keep quantum JSON only.  but i'm willing to debate :)
21:23:03 <nati_ueno> +1 for JSON only
21:23:15 <zhuadl> +1 for XML support :-)
21:23:16 <markmcclain> +1 for json only
21:23:20 <salv-orlando> In my opinion, the first choice we should make is whether we believe we can decide on our own, or whether we should rely on the decision of openstack as a whole
21:23:22 <PotHix> +1 for JSON only
21:23:36 <lzyeval_> +1 for only json
21:23:38 <danwent> salv-orlando: apparently, there are already projects that do not support XML
21:23:47 <salv-orlando> great.
21:23:55 <nati_ueno> What's happen for nova is they can't get enough contributer for XML. So XML support is very poor.
21:24:01 <danwent> at some point, openstack as a whole may decide to mandate XML support, in which case we would obviously comply
21:24:19 <cdub> "The OpenStack Quantum API supports both the JSON and XML data serialization formats. "
21:24:24 <lzyeval_> nova is only going to support xml apis which already exists
21:24:25 <cdub> quick, rewrite the docs
21:24:29 <salv-orlando> We are in a position where we are free to make any decision without disrupting anybody, as this is our first "public" release
21:24:32 <edgarmagana> shouldn't be a topic to discuss during the next summit?
21:24:45 <danwent> edgarmagana: next summit is too late for Folsom
21:24:51 <salv-orlando> edgarmagana: indeed, so...
21:25:04 <salv-orlando> I say Folsom will have no XML support.
21:25:19 <danwent> basically, if we want to support XML, we'll need to find someone who signs up for seriously standing behind it
21:25:19 <salv-orlando> We'll discuss whether we want to add it as part of quantum v2.1 at the summit
21:25:23 <danwent> in quantum
21:25:35 <zhuadl> I'm willing to help on this
21:25:39 <danwent> we also need to answer more practical questions, like how we represent "null" values
21:25:46 <salv-orlando> danwent: at the end of the day, I believe it boils down to serialization/deserialization
21:25:54 <cdub> danwent: is/was there XML support of nova-networks (in which case it'd be a pure parity requirement I'd think)
21:26:00 <salv-orlando> in quantum v1 already had test instrastructure to cover both in the same way
21:26:04 <edgarmagana> danwent: my point is that we should discuss it during the summit and by now just JSON support
21:26:13 <danwent> cdub: there was no official nova api that exposed networks
21:26:22 <danwent> and even if there was, I don't see it as parity
21:26:23 <lzyeval_> danwent: doesn't json have null value?
21:26:36 <lzyeval_> danwent: oh xml u mean
21:26:40 <danwent> lzyeval_: yes
21:26:42 <cdub> ok
21:27:03 <danwent> anyway, if we decide to support XML for folsom, I'd consider if for an FFE
21:27:10 <salv-orlando> danwent: I would not put absence of null value as an excuse for not supporting xml :)
21:27:27 <salv-orlando> and if we make that decision, that we will have to stand by it, at least until we release quantum v3
21:27:29 <danwent> but I'd want to see a very credible plan for how someone introduces support, unit testing etc, so XML support is actually a first-class citizen.
21:28:00 <danwent> salv-orlando: i'm just saying that its a practical question we'd have to tackle in the next week or so.
21:28:15 <danwent> (i.e., how to represent null) since our API design includes it.
21:28:33 <salv-orlando> danwent: agreed.
21:28:46 <danwent> so zhuadl, cdub, others who are interested in XML support.  do you want to work with each other to put something together on this?
21:28:47 <zhuadl> i remember xml is able to support null value
21:29:07 <danwent> zhuadl: great.  i'm not saying it doesn't, just that I'm not sure how it does.  I don't use XML much :)
21:29:10 <salv-orlando> I used to use emptty elements as null values
21:29:10 <zhuadl> yes, i can
21:29:37 <zhuadl> xml has nullable definition
21:29:40 <danwent> ok, thanks.  Even if this is given an FFE, the work would have to be done pretty quickly.
21:29:54 <cdub> danwent: i'm actually not interested as much as i'd like to avoid some last minute firedrill if we there are clear reasons why it has to be done ;-)
21:29:57 <salv-orlando> You can stack your work on top of andrews patch
21:29:58 <danwent> please take a look at the work andrewsmedina did and is posted to gerrit
21:30:42 <danwent> cdub: got it.  I already have clearence from ttx to not support it if the community does not want to support it.  but if there is community demand and those members are going to do a good job on nit, I"m happy to have XML support.
21:30:54 <danwent> Ok, zhuadl please send something out on this soon, ok?
21:31:06 <danwent> #todo zhuadl send plan for XML support in Folsom
21:31:15 <zhuadl> ok
21:31:20 <danwent> please include andrewsmedina as well, as he's done some work on this.
21:31:30 <danwent> ok, next topic:  rootwrap
21:31:56 <danwent> rkukura: plan is to not merge Thierry's patch, and instead merge a patch from RH that fixes up quantum?
21:32:07 <rkukura> sounds good to me
21:32:10 <cdub> danwent: jrd has a conflict w/ this irc time, but his email status is basically up to date
21:32:32 <cdub> danwent: although he's not 100% confident he can make it done and reviewed by tomorrow
21:32:48 <danwent> yup, saw the email.  I think he should target having it done ASAP, though as I said, an FFE would be feasible for this, as the community benefit is obvious.
21:32:58 <danwent> next topic.
21:33:12 <cdub> *nod*
21:33:15 <danwent> nati_ueno has a patch that introduces a 'device_owner' attribute on a port
21:33:34 <nati_ueno> https://review.openstack.org/#/c/10922/
21:33:37 <danwent> the reason for this is that we found that people where often mangling device_ids with the source of the device
21:33:46 <danwent> e.g., dhcp, qrouter, etc.
21:34:00 <danwent> it will also add in debugging to be able to see which ports are owned by which service.
21:34:15 <nati_ueno> This could be used for transaction support also.
21:34:17 <salv-orlando> I am going to review patch 10922
21:34:19 <danwent> anyway, I think it makes sense, but wanted to raise it here to see if there were concnerns.
21:34:28 <salv-orlando> No concern from me.
21:34:42 <danwent> ok, any other deveoper discussion topics?
21:34:59 <markmcclain> need a review on https://review.openstack.org/#/c/11278/
21:35:03 <danwent> I also just wanted to not that Salvatore is working with Docs people at Rackspace to get an official V2 API spec out.
21:35:40 <danwent> markmcclain: just +2'd
21:36:02 <nati_ueno> If you need more debug command for quantum, please ping me :) https://review.openstack.org/#/c/11189/9/quantum/debug/README
21:36:04 <danwent> I will also be hounding people to help write docs once F-3 features are in
21:36:33 <gongys> Our quantum.sh in devstack is running?
21:36:48 <danwent> gongys: nati_ueno is working on the v2 version of that.
21:36:49 <garyk> i have been unable to get it running
21:36:51 <nati_ueno> gongys: Not yet. I'm debugging it
21:36:54 <danwent> i haven't tested it in a few days
21:37:08 <danwent> but that is critical to getting quantum devstack gating working, which i mentioned earlier.
21:37:19 <danwent> once F-3 features are in, that will be top priority for the community
21:37:33 <danwent> this will help a ton with avoiding breakage
21:37:37 <gongys> Is quantum gate testing  enabled in jenkin env?
21:37:58 <gongys> which will call our quantum.sh.
21:38:03 <danwent> gongys: no, we need to get the new quantum.sh merged in, then jeblair will turn it on
21:38:15 <gongys> ok.
21:38:34 <danwent> #topic open discussion
21:38:36 <danwent> anything?
21:38:41 <danwent> or back to reviews?
21:38:57 <nati_ueno> danwent: Could you take a look? I fixed your point.  https://review.openstack.org/#/c/10922/
21:39:09 <danwent> as I said, it was an incredible effort from several team members over the weekend that got us in good shape.  thanks for all the hard work.
21:39:10 <nati_ueno> and alos https://review.openstack.org/#/c/10639/
21:39:34 <danwent> nati_ueno: ok, will look.  i have a stack of reviews, as well as my own coding to do later today ;)
21:39:47 <danwent> any other open discussion?
21:40:05 <nati_ueno> danwent: Thanks!
21:40:10 <danwent> otherwise, stick around if you want to discuss the quota extension issue with gongys and i, otherwise, ill talk to you all next week
21:40:18 <salv-orlando> k
21:40:18 <nati_ueno> let's have a meet up after F3
21:40:22 <carlp> thanks dan!
21:40:42 <danwent> nati_ueno: i'm actually putting an on-site bug squashing even together
21:40:46 <danwent> thanks folks
21:40:49 <danwent> #endmeeting