21:01:24 <danwent> #startmeeting quantum
21:01:25 <openstack> Meeting started Mon Feb 18 21:01:24 2013 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:28 <danwent> hi folks
21:01:29 <openstack> The meeting name has been set to 'quantum'
21:01:42 <danwent> #info agenda: https://wiki.openstack.org/wiki/Network/Meetings
21:01:59 <danwent> note that we have switched to a new wiki.  if any sub-team leads are having trouble accessing it, let me know.
21:02:01 <garyk> hi
21:02:12 <danwent> we have a few US people out due to a holiday today
21:02:25 <danwent> #topic announcements
21:02:29 <danwent> #info G-3 branch date is TOMORROW Feb 19th.
21:02:40 <danwent> #info: All features must be merged by tomorrow EOD (11:59pm PST).
21:02:50 <danwent> #info: Core devs: be vigilant against last minute "rush reviews"
21:02:52 <SumitNaiksatam> hi all!
21:03:05 <danwent> I can't stress this point enough…. letting in sub-standard code always comes back to bite us in the ass
21:03:25 <danwent> and wreaks having on the noble folks who maintain the stable branch (garyk most of all!)
21:03:41 <danwent> #info We will not be giving feature freeze exceptions for non high/critical issues.
21:03:52 <danwent> #info Remember to file doc bugs as we merge in G-3 features.
21:04:10 <danwent> starting next week, we should be focused on:
21:04:19 <danwent> 1) dealing with any feature freeze exceptions (FFE)
21:04:38 <danwent> 2) pairing down our list of bugs to those that are truly serious
21:04:49 <danwent> 3) making sure we are spinning up the documentation machine
21:04:57 <danwent> any other announcements before we move on?
21:05:23 <danwent> #topic bugs (markmcclain )
21:05:57 <markmcclain> we have 6 high bugs that are not merged
21:06:04 <markmcclain> https://bugs.launchpad.net/quantum/+bug/1112912
21:06:06 <uvirtbot> Launchpad bug 1112912 in quantum "get_firewall_required should use VIF parameter from quantum" [High,In progress]
21:06:10 <markmcclain> https://bugs.launchpad.net/quantum/+bug/1121119
21:06:12 <uvirtbot> Launchpad bug 1121119 in quantum "Metadata support for the NVP plugin" [High,In progress]
21:06:19 <markmcclain> are in review.. please take a look
21:06:44 <danwent> markmcclain: are we covering db locking bug in db section?
21:06:56 <garyk> markmcclain: i think that the vif one requires nova support.
21:07:01 <markmcclain> I need to move it up.. I have it IPAM
21:07:18 <danwent> markmcclain: that's ok, just want to make sure we get that covered, as we need to backport that to stable asap
21:07:40 <danwent> also, i saw this come in today: https://bugs.launchpad.net/quantum/+bug/1128931
21:07:41 <uvirtbot> Launchpad bug 1128931 in quantum "l3-agent can not find Endpoint" [Undecided,New]
21:07:58 <danwent> would be good to get that triaged prior to G-3
21:08:31 <garyk> danwent: i'll take a look at that one tomorrow morning
21:08:34 <markmcclain> yeah.. this one is interesting because we use RPC, so it only applies to folsom
21:08:36 <danwent> nati_ueno: my understanding is that there's still discussion on get_firewall_required stuff?
21:08:47 <nati_ueno> yes
21:09:01 <danwent> markmcclain: good point, so yeah, i guess applies only to stable, g-3 is irrelevant
21:09:18 <nati_ueno> i got new comment from daniel
21:09:20 <danwent> #todo danwent comment on get_firewall_required bug after meeting
21:09:46 <danwent> markmcclain: btw, i invalidated https://bugs.launchpad.net/quantum/+bug/1111572
21:09:48 <uvirtbot> Launchpad bug 1111572 in quantum "quantum subnet-update can't update allocation-pool " [High,Invalid]
21:09:55 <danwent> since it seems like we don't want to change the API spec
21:10:05 <danwent> markmcclain: so you can take it off your list
21:10:18 <markmcclain> ok.. I missed the status change
21:10:21 <markmcclain> I'll update
21:10:38 <danwent> ok, anything else before we move on?
21:10:56 <markmcclain> that's all for now
21:11:24 <danwent> #topic api (salv-orlando)
21:11:31 <salv-orlando> hi all.
21:12:03 <salv-orlando> as you can read in the status, there nothing serious (critical, high) on the API side. However we really might use a core dev for merging the pagination patch.
21:12:17 <markmcclain> I owe Alex a review on that one
21:12:18 <salv-orlando> it's very mature, so I suspect it should be an easy review.
21:13:01 <salv-orlando> I am afraid we will not have enough review cycles for completing the WADL blueprints. nati-ueno is the only one who did some reviews.
21:13:06 <danwent> ok, salv-orlando do we still have a bug filed for grizzly to validate API input to avoid issues with mispellings, etc that are silently ignored?
21:13:13 <salv-orlando> Yes, it under review.
21:13:24 <salv-orlando> It's a very small patch (+5, -0)
21:13:33 <danwent> i think that is very important, so can you post a link?
21:13:49 <danwent> i know lots of people who would be happy to take a look at a 5 line review after the monsters we've been doing through lately :)
21:14:04 <zyluo> salv-orlando: can the wadl patch also have some cores?
21:14:11 <garyk> my kindom for a review of afew lines
21:14:18 <gongysh> :)
21:14:47 <zyluo> S/can/could
21:14:53 <salv-orlando> zyluo: I can do a review tomorrow morning, but I am afraid I can't make a commitment to have it merged
21:15:14 <salv-orlando> https://review.openstack.org/#/c/21849/ <-- the small patch from Jason Zhang (bearovercloud)
21:15:21 <danwent> ok, so it sounds like both the WADL and pagination patches need people to step forward if folks really want to see them in grizzly.  In both cases, I'm not very worried about rushed reviews, as salv-orlando says the pagination stuff is mature, and the wadl stuff is not code that runs as part fo the service
21:15:26 <salv-orlando> you must merge a patch from somebody with that nick
21:15:42 <danwent> ok, anything else on the API?
21:15:49 <salv-orlando> no, that is all my master
21:16:07 <danwent> #topic L3/IPAM/dhcp (markmcclain)
21:16:20 <danwent> btw, the last-update field of "now" is not very helpful :P
21:16:27 <markmcclain> :)
21:16:40 <danwent> garyk's suggestion of using the signature if perfect
21:16:56 <markmcclain> Good news… Part 1 of Yong's scheduler patch has merged
21:17:02 <danwent> yup, great
21:17:13 <markmcclain> cores please take a look at https://review.openstack.org/#/c/21069/
21:17:40 <markmcclain> Yong has been super responsive to make sure this merges in time for G3
21:17:40 <nati_ueno> awesome
21:17:56 <danwent> ok, i think this is probably our highest priority item outstanding
21:18:03 <markmcclain> right
21:18:14 <markmcclain> take a look at part 2 first
21:18:18 <markmcclain> and then comment on part 3
21:18:21 <danwent> so if you're doing a lot of reviews, but this one is languishing, something is wrong :)
21:18:26 <markmcclain> https://review.openstack.org/#/c/21175/
21:18:37 <markmcclain> That is the last high item for G3
21:18:50 <salv-orlando> what about part 1? did it already merge (it looked quite mature to me)
21:18:59 <markmcclain> salv-orlando: yes… today
21:19:01 <salv-orlando> oh sorry - missed a line
21:19:09 <amotoki> part 2 looks near merge.
21:19:28 <amotoki> part 3 needs more reviews.
21:19:48 <gongysh> part 3  is still monster.
21:20:02 <markmcclain> yeah.. I suspect most attention was on part 1 now we need to check out parts 2 and 3
21:20:08 <garyk> for part 2 do we want the notifications in each plugin. this cncerns me
21:20:25 <danwent> garyk: yeah, i was wondering about the same thing.
21:20:35 <danwent> seemed like maybe we could extract it out
21:20:46 <danwent> anyway, probably more of a review board discussion
21:20:58 <garyk> danwent: ok
21:21:10 <gongysh> the same problem to security group and other extensions.
21:21:20 <danwent> garyk: sorry, just trying to end meeting before its too late :P
21:21:21 <gongysh> ?
21:21:32 <gongysh> right?
21:21:36 <garyk> danwent: np. understood.
21:22:01 <danwent> gongysh: let's move discussion to gerrit to keep meeting moving, as I don't think the comment was a fundemental concern
21:22:07 <danwent> markmcclain: go ahead
21:22:32 <markmcclain> I want to thank garyk for fixing last weeks documentation bug
21:22:43 <danwent> woohoo!
21:23:00 <amotoki> garyk: thanks!
21:23:18 <garyk> thanks to amotoki for the info :)
21:23:35 <markmcclain> and the last item for my report is the proposed fix for the DB IP Allocation bug
21:23:52 <markmcclain> https://review.openstack.org/#/c/21424/
21:24:12 <markmcclain> the fix uses a select..for update SQL query under the hood
21:24:25 <markmcclain> to lock the row until the transaction is complete
21:24:42 <markmcclain> there are two −1s… I'm ready to remove mine
21:24:54 <danwent> markmcclain: i need to re-read that patch, as its not clear to me how the case where we allocate a specific IP is covered.
21:25:15 <danwent> but if we're confident it is, i'm fine removing my -1
21:25:26 <danwent> don't need to explain it now
21:25:30 <danwent> we can handle it on review
21:25:49 <markmcclain> ok.. I just wanted to call attention the review because it will impact both G3 and stable
21:26:05 <danwent> yup, agreed.
21:26:09 <markmcclain> that is it for my report
21:26:10 <danwent> one other item i wanted to bring up: https://bugs.launchpad.net/quantum/+bug/1056437
21:26:11 <uvirtbot> Launchpad bug 1056437 in quantum "L3 agent should support provider external networks" [High,In progress]
21:26:23 <danwent> rkukura couldn't make it today, but he is planning on working on this
21:26:36 <danwent> its valuable, and has been hanging around since just before folsom release
21:27:01 <danwent> if we're going to do this, i think we need to wrap it up soon, as touches some pretty critical code
21:27:14 <danwent> ok, sounds like we're good on l3/ipam/dhcp?
21:27:34 <danwent> #topic nova quantum integration (garyk)
21:27:46 <garyk> some minor stable fixes.
21:28:21 <garyk> not sure if we need to make changes for the vif firewall. nati_ueno  or amotoki you guys aware of that?
21:28:49 <nati_ueno> imo it should be
21:29:04 <garyk> nati_ueno: thnks
21:29:25 <amotoki> If we don't use generic VIF driver, we don't need to update it, but idealy it should be.
21:29:26 <garyk> there is also https://review.openstack.org/#/c/21819/ - add port for hot plug which touchs on quantum from nova
21:29:54 <danwent> garyk: i promised vishy i would review that later today
21:30:05 <danwent> so will be looking at it right after meeting
21:30:08 <garyk> danwent: thats it. we should follow up on the vif/firewall side on nova
21:30:17 <danwent> ack on both accounts
21:30:28 <danwent> security / firewalling (arosen)
21:30:33 <garyk> danwent: i looked this morning and need to look after the patch was updated
21:30:36 <danwent> #topic security /firewallg (arosen)
21:30:43 <arosen> The NEC, NVP, OVS patches merged for this.
21:30:47 <danwent> garyk: yes, seems like there is a new patch owner… odd
21:30:49 <garyk> i think arosen is too busy fixing bugs :)
21:31:01 <arosen> There is a patch  for RYU that implements security groups that's still up for reveiw.
21:31:26 <arosen> My nova changes are still also up for review which hopefully should merge soon.
21:31:52 <arosen> that's about it on the security group side.
21:32:18 <danwent> arosen: ok, those nova security group proxy patches are important
21:32:49 <danwent> seems like vishy is on board with them getting in, but i'll re-check with him
21:32:57 <arosen> will do
21:33:02 <vishy> I'm on board
21:33:03 <vishy> :)
21:33:05 <danwent> anything else?
21:33:11 <danwent> vishy: ha, thanks :)
21:33:27 <danwent> vishy: do you expect problems getting a second core?
21:33:39 <vishy> danwent: we shall see :)
21:33:54 <danwent> ok… i can go begging if needed :)
21:34:18 <danwent> #topic LBaaS (danwent)
21:34:29 <danwent> ok, this one got very interesting in the past few days
21:34:58 <danwent> basically, we weren't happy with the current state of things with lbaas, and as is, the code was not going to make the standard grizzly cut-off
21:35:35 <danwent> we were faced with the option of either not having any in-tree lbaas impelmentations for grizzly, or drastically simplifying things and trying to push that into grizzly with a FFE
21:35:57 <danwent> markmcclain has volunteered to work with the mirantis team on the latter
21:36:25 <danwent> the model is basically to simplify things by using a namespace + agent approach similar to DHCP, and to leverage the haproxy code from the existing patch to write config files, etc.
21:36:31 <danwent> for haproxy.
21:36:42 <danwent> we're going to request a one-week FFE from ttx tomorrow.
21:37:11 <danwent> here is ha-proxy driver review, which will remain intact except for the "remote control" stuff to manage VMs (https://review.openstack.org/#/c/20985/)
21:37:37 <zykes-> So, No LBaaS in G?
21:37:39 <danwent> and markmcclain is using https://blueprints.launchpad.net/quantum/+spec/lbaas-namespace-agent to track the simplified agent approach.  he expects to have a branch posted late tues/ early wed.
21:37:48 <danwent> zykes-:  we'll see, its still pending
21:37:49 <salv-orlando> danwent: so paramiko dependency is definetely gones?
21:37:53 <zykes-> ok :)
21:38:01 <danwent> salv-orlando: yes, all use of SSH to access VMs would be gone
21:38:08 <danwent> since there wouldn't be VMs
21:38:33 <danwent> I think we'll huddle again on the #quantum-lbaas channel on thurs to see if we feel like we have enough to push for grizzly
21:38:50 <salv-orlando> ok, I can take some of the review burden out of markmcclain's hands. I'll sync with him to see which patches I should look at first
21:38:52 <danwent> i'll have one of the developers send out a note about it.
21:39:06 <danwent> salv-orlando: great, thanks… that would be helpful
21:39:09 <markmcclain> salv-orlando: thanks!
21:39:16 <danwent> markmcclain: anything else to add?
21:39:27 <markmcclain> you covered it for now
21:39:53 <danwent> #topic quantum client / cli
21:39:57 <danwent> gongysh + markmcclain
21:40:02 <gongysh> hi
21:40:18 <gongysh> No code for Make QuantumClient library more pythonic
21:40:20 <danwent> looks like content is still from last week?
21:40:28 <danwent> or just no change to last-updated? :P
21:40:35 <gongysh> markmcclain is busy.
21:40:50 <danwent> haha, no kidding :)
21:41:23 <danwent> ok, so are we still planning on making that change?  seems somewhat risky?
21:41:24 <gongysh> we needs review for allow known options be put after unknown options in list and update commands
21:41:56 <danwent> have we set a "feature freeze" date for the client 3.0 release ?
21:42:16 <gongysh> no.
21:43:01 <danwent> ok, if you plan to, definitely let people know a bit ahead of time
21:43:04 <gongysh> but we need to publish a milestone for G server.
21:43:30 <danwent> sorry? "G server"?
21:43:52 <gongysh> this phthonic does not impact feature to access quantum server G, so, we can go without it.
21:44:17 <gongysh> G server -> quantum server G
21:44:34 <danwent> ah, the grizzly version of quantum-server… got it.
21:44:45 <gongysh> we needs review for allow known options be put after unknown options in list and update commands
21:45:01 <danwent> ok, so is the thought that we would pushing a 2.x compatible with grizzly, then update to 3.0 potentially out of sync with server releases?
21:45:14 <amotoki> gongysh: i am looking it. I have no more comments than Gary commented.
21:45:28 <gongysh> amotoki: thanks
21:45:49 <danwent> gongysh + markmcclain : both please send PGP keys to monty so that you can push tags indicating client releases yourself.
21:46:10 <markmcclain> will do
21:46:16 <gongysh> danwent: will do.
21:46:43 <gongysh> danwent:  yes, that is the plan
21:46:48 <danwent> gongysh: thx
21:46:50 <gongysh> danwent: IMO
21:47:13 <danwent> #info we plan to release python-quantumclient 2.x compatible with grizzly, then separately release a 3.0 with new pythonic interface (likely before havana)
21:47:15 <gongysh> There are some other patches lacking reviews too.
21:47:32 <danwent> gongysh: btw, we should then add a new milestone on launchpad for the 2.x release and retarget things
21:47:32 <gongysh> on python quantum client
21:47:37 <danwent> gongysh: please highlight
21:47:54 <gongysh> https://review.openstack.org/#/q/status:open+project:openstack/python-quantumclient,n,z
21:49:16 <gongysh> about a new milestone, I will talk with markmcclain.
21:49:22 <danwent> gongysh: great, thanks.
21:49:44 <gongysh> no other stuff from my side.
21:49:49 <danwent> once the feature-set of grizzly is defined by what merged tomorrow night, we can know exactly what CLI stuff needs to be in the corresponding client version.
21:49:51 <danwent> gongysh: thanks.
21:50:12 <gongysh> by the way, the action=clear is the previous topic at last meeting?
21:50:16 <danwent> as mentioned in my email, i'm planning on skipping systemtest and stable sections, due to G-3 deadline
21:50:18 <gongysh> what is the result?
21:50:53 <danwent> gongysh: was there a final decision made on that?
21:51:22 <danwent> gongysh: can we add a bug to the 2.x release to finalize our plan for that?
21:51:25 <gongysh> no, as far as I know. the patch is expired.
21:51:35 <danwent> we'll have to add python-quantumclient release as another focus area for meeting next week.
21:51:49 <danwent> (I will be reformatting agenda for that meeting, since we are in release mode)
21:51:59 <danwent> #topic quantum + horizon (amotoki + nati_ueno)
21:52:25 <amotoki> vnic-oridering has been merged. quantu-lbaas has a good progress.
21:52:34 <amotoki> nachi's network-topology has got one +2.
21:52:51 <danwent> great
21:52:53 <amotoki> I hope someone else tests it.
21:53:05 <amotoki> one concern is my secgroup-support.
21:53:30 <amotoki> I encountered the trouble during development.
21:53:52 <amotoki> I will send a mail to Gabriel to discuss the future plan.
21:53:53 <danwent> ok.  seems like this may be too big of an item for G-3
21:54:05 <danwent> please keep me in the loop on the email
21:54:19 <amotoki> danwent: sure, of cource.
21:54:35 <danwent> but it may be best to leave this for Havana, so we can make sure we don't overwhelm the reviewing resources from horizon
21:54:48 <danwent> seems like a lot of their patches are from the quantum team lately, you guys have been doing a great job :)
21:55:05 <danwent> #topic open discussion
21:55:14 <amotoki> danwent: agree with you
21:55:17 <danwent> one item i wanted to mention was: https://review.openstack.org/#/c/21520/
21:55:30 <danwent> this is the fact that people can delete nova ports directly from quantum
21:55:59 <danwent> the question is whether the API should look at device_owner + device_id and prevent this, or if the CLI / GUI should simply do this check
21:56:16 <danwent> my concern with doing it in the API is that it requires nova to do two calls to tear down a VM, rather than one.
21:56:22 <danwent> (i.e., clear device-id, then delete)
21:56:28 <danwent> which seems silly
21:56:35 <zykes-> dhellmann: question, will there be any ideas around supporting stuff like Port Mirroring from the API ?
21:56:46 <garyk> danwent: i agree with you
21:56:49 <salv-orlando> apart from this, the implications of this patch are manifold
21:57:04 <salv-orlando> basically this means that I can create a port, own it, and the lose its ownership as soon as I attach it to a VM
21:57:10 <danwent> anyway, pleaese give opinions on the review… but i would like to see some resolution to this issue in grizzly
21:57:29 <danwent> any other open discussion?
21:57:35 <danwent> zykes-: was that a question for us?
21:57:49 <danwent> ah, you probably mistakenly typed dhellmann
21:58:00 <zykes-> danwent: yeah, since we hit open discussion I thought I'd ask for @ Havana
21:58:03 <zykes-> :)
21:58:28 <markmcclain> I'll be speaking at the OpenStack LA Thursday Feb 28th: http://www.meetup.com/OpenStack-LA/events/103087832/
21:58:32 <danwent> zykes-: got it.  Yeah, NVP has support for things like port mirroring, so I think salv-orlando or arosen may be working on something like that.
21:58:51 <danwent> markmcclain: nice… wish I could roadrip down there :P
21:59:16 <danwent> markmcclain: looks like a good crowd already
21:59:24 <danwent> ok, we're about out of time
21:59:47 <danwent> going once...
21:59:52 <danwent> oh, one more reminder
22:00:30 <danwent> please please please be careful about merging code that is not ready, just because a developer really wants a feature in a release, doesn't mean its the right thing for the community to have to support and fix that feature.
22:00:55 <danwent> ok, two bigs days of reviewing.  please remember that gongysh's patch and the lbaas stuff are our two high priority community BPs
22:01:02 <danwent> see you all on gerrit!
22:01:06 <danwent> #endmeeting