21:00:53 #startmeeting quantum 21:00:54 Meeting started Mon Nov 12 21:00:53 2012 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:54 mestery: by a whisker 21:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:57 The meeting name has been set to 'quantum' 21:00:59 Hello world! 21:01:07 hooray, meetbot is back in the world of the living :) 21:01:16 #info agenda is here: http://wiki.openstack.org/Network/Meetings 21:01:43 magana: it should be _("Hello world!") 21:01:51 hi 21:01:51 #info we are one week out from G-1 branch point next tuesday. All non-critical bugs targeted for G-1 must be in by next tuesday when we branch 21:02:00 hi 21:02:06 #topic grizzly-1 21:02:15 so here is current status 21:02:17 #link http://wiki.openstack.org/Network/Meetings 21:02:20 oops 21:02:26 #link https://launchpad.net/quantum/+milestone/grizzly-1 21:02:29 much better :) 21:02:59 it seems like most of you (with some pestering) updated the 'delivery' status of your items, thank you for htat. 21:03:22 garyk: if magana == mistake then dummy_mode = enabled 21:03:54 We'll first talk about any items that are 'high' or above, then go through reviews in more detail to make sure we have all important bugs and or blueprint covered from a review perspective 21:04:07 Hi All 21:04:10 nati_ueno_2: quantum gate stuff is in review 21:04:14 we'll talk about that in a bit 21:04:20 danwent: I got it 21:04:31 salv-orlando: service type defition status. proposed for review soon? 21:04:40 otherwise, will need to be G-2 21:05:05 danwent: I started coding today. I noted on the blueprint that if I don't have code ready by weds I will postpone 21:05:12 #info btw, if you're looking for help with any blueprints that you've signed up for, let me know, as I have a few people pinging me looking for things to work on. 21:05:46 salv-orlando: ah, i see that on the whiteboard, thanks for updating 21:05:59 nati_ueno: iptables impl of security groups. 21:06:12 I'll push the code until Wednesday 21:06:30 Coding is almost finished. I'm testing it now 21:06:44 ok, if you feel that you're close 21:06:55 i'm a bit worried that this may be a large change-set that will take a lot of review cycles. 21:07:04 can we try and identify the people who would review it right now? 21:07:34 I'll help 21:07:41 I suspect arosen would be up for it, since he did security groups for the nicira plugin already 21:07:50 I was going to suggest him 21:07:51 zyluo: thanks. 21:08:01 will do. 21:08:06 amotoki: ok, great. 21:08:18 nati_ueno: can you be sure to keep those three folks updated when you push? 21:08:20 OK Thanks! zyluo, arosen, amotoki 21:08:24 I got it 21:08:38 https://blueprints.launchpad.net/quantum/+spec/rpc-for-l3-agent 21:08:46 https://review.openstack.org/#/c/15476/ 21:08:57 seems markmcclain has something to say. 21:08:58 this is under review, but it seems like there are still some design discussions going on? 21:09:27 I added comments to the Google doc 21:09:52 markmcclain: which doc? 21:10:11 https://docs.google.com/document/d/1rWp41OnCwivj2sMazeNkD3RTf1rL_GzV2f9Fud5FNjY/edit?pli=1#heading=h.98sjs99uphl8 21:10:14 Ok, do we have two core devs working on this, such that if design decisions are addressed, we can review in time? 21:10:20 or following the link from the bp 21:10:42 thanks-salv-orlando. Originally I thought the plan was to make the agent<>service communication more efficient. The work is heading a different direction 21:10:58 markmcclain: yeah, that was my goal in creating the BP 21:11:11 hi, I need to read your comments. 21:11:13 salv-orlando: Thanks 21:11:16 basically to remove the need to poll with the L3-agent, essentially the same thing we did for the l2-agents 21:11:26 BUt I think the direction is right way. 21:11:38 more efficient. 21:11:46 I think that would be gongysh goal. From what I gather it seems the design is actually more complex than what it needs to be. 21:11:54 I disagree… the line between agent/server is muddied 21:12:02 This might end up in a long discussion. 21:12:07 salv-orlando: i agree 21:12:16 we can discuss after the meeting to keep things moving 21:12:20 ok, the point of the meeting is to flag potential issues 21:12:27 ok 21:12:50 do the three of you think its enough to continue talking on gerrit? otherwise, perhaps try to meet up on openstack-dev 21:12:59 (but not during main quantum meeting :p) 21:13:23 sounds like we do have two core devs working on the review though, which is good. 21:13:30 I think via the ML or IRC 21:13:30 https://blueprints.launchpad.net/quantum/+spec/quantum-service-framework 21:13:53 is eugene here? 21:13:58 yep 21:13:59 I will be helping Salvatore with testing and reviews 21:14:11 enikanorov_: hi :) 21:14:18 hi folks! 21:14:33 can you provide a quick update on the status of this, anything that is blocking you, and whether you think it can be merged for g-1? 21:15:01 I hope to merge it tomorrow if i don't recieve more comments 21:15:08 looks like garyk and salv-orlando are taking care of you from a review perspective, so we're covered there. 21:15:12 just fix remaining few 21:15:18 yep 21:15:31 enikanorov_: well, awesome. and welcome to the team. 21:15:38 thank you :) 21:15:44 Technically , bar a few nits, it's good to merge. I have still a little concern over the fact that at the moment it allows for having multiple APIs for the same class of service 21:16:04 but it is something we can perhaps address with a follow-up patch. I don't want to hold up the lb work. 21:16:04 salv-orlando: you mean multiple plugins for the same "service" api? 21:16:21 salv-orlando: yeah, just make sure we file a bug and target it for G-2 21:16:22 Nope. I mean multiple LB API extensions exposed to the tenant. 21:16:31 salv-orlando: ah, i get it 21:16:39 https://blueprints.launchpad.net/quantum/+spec/metadata-overlapping-networks 21:16:41 markmcclain: 21:16:59 salv-orlando: are there any docs to describe the spec for service framwork? 21:17:07 as i mentioned on whiteboard, we should either update this to good progress with indication of a review by Wed, or move to G-2. 21:17:36 amotoki: for the patch under review, see the bp whiteboard (I don't recall the link to enikanorov_ wiki page) 21:17:44 close to posting for review… had to make a few changes to isolated networks (ie no router) 21:18:09 markmcclain: ok, great. even a WIP branch would help some people start reviewing it. 21:18:18 have we identified two core reviewers? 21:18:32 danwent: i'll review 21:18:40 garyk: k, great. i can reivew that one as well 21:18:50 as i'm pretty interested to see the proposed solution. 21:19:02 me too 21:19:02 ok, markmcclain: garyk and I will be your contacts. 21:19:09 cool 21:19:22 ok, that's every that is high or above for G-1 blueprints 21:19:41 remember to priortize your review cycles based on the priority of the blueprint or bug 21:19:53 I'd also like to encourage people to spend cycles on bugs that affect folsom 21:20:19 garyk has been spending a ton of his cycles fixing these issues, and we need to make sure we spread the load :) 21:20:35 we're targeting a stable/folsom release along with G-1 21:20:48 so getting those fixes in, and then backported to stable/folsom is important. 21:21:07 #info current list of folsom-backport-potential bugs: https://bugs.launchpad.net/quantum/+bugs?field.tag=folsom-backport-potential 21:21:36 ok, next I was just going to make sure we were covered for any important (particularly folsom relevant) bugs currently under review. 21:21:44 https://review.openstack.org/#/c/14990/ 21:21:52 this is devstack review for quantum gating 21:21:55 garyk and I are reviewing 21:22:01 I think this is pretty much good to go. 21:22:16 garyk, did you confirm that volume issue you were seeing is not related to this? 21:22:28 danwent: yes. 21:22:47 danwent: i also saw some patches with smokestack addressing volumes 21:22:52 garyk: great. Ok, i'm planning on +2-ing after the meeting. any blocker on your end? 21:23:10 danwent: no. tomorrow morning i'll do this first thing 21:23:18 sweet, great work on this nati_ueno 21:23:24 +1 21:23:26 https://review.openstack.org/#/c/15747/ 21:23:41 this is the bug to fixe quota performance by doing a count() lookup, rather than fetching all items 21:23:47 i'm one reviwer, but I think we need a second 21:23:53 patch is close to being good to go. 21:23:55 I can review 21:24:05 markmcclain: thx 21:24:09 danwent: I will be helping Juergen and getting this fixed and reviewed 21:24:29 magana: great. he responded to first round of feedback, and so I think we're now close 21:24:33 https://review.openstack.org/#/c/15829/ 21:24:41 danwent: as you said, we are getting close to complete 21:24:43 fix to ip allocation logic from garyk. currently, no core devs 21:24:54 are you sure :) 21:25:01 errr… i'm wrong 21:25:15 looks like we have 3, so we're good to go 21:25:27 danwent: i need to address comments. tomorrow it will be ready for next round :) 21:25:35 garyk: thx 21:25:46 floodlight/bigswitch plugin: https://review.openstack.org/#/c/15071/ 21:25:51 seems like we have two core devs 21:25:51 garyk: i like to review this as well 21:26:02 comments imply that we are close to merge here, so seems ok for g-1? 21:26:09 magana: ok 21:26:14 yeah.. just needs a few classes to be renamed 21:26:28 markmcclain: great. 21:26:30 i think so too. 21:26:48 this one is already fine with respect to our core dev maintainer policy, as sumit is a core 21:26:59 https://review.openstack.org/#/c/15758/ 21:27:08 my patch for fixing some floating IP allocation checks 21:27:17 gongysh: let's chat after the meeting about your question 21:27:23 yes 21:27:32 I can play 2nd core on that patch 21:27:40 salv-orlando: beat me to the question :) 21:27:49 https://review.openstack.org/#/c/15022/ 21:27:52 xenserver support for OVS 21:28:15 hasn't see a lot of activity lately 21:28:22 looks like it was just restored 21:28:34 mnewby: do we have core devs actively working on this review yet? 21:28:37 I've tried to review that patch, but I need some more cycles to build infrastructure for live testing 21:28:44 same here 21:29:12 ok, so is this realistic for G-1, or should be bump to G-2? 21:29:13 i'd like to but i have never used xen so i am nure i'd be much help here 21:29:28 danwent: The lack of easy testing is complicating things. 21:29:39 mnewby: yeah, understoood 21:29:52 I need a full day, so I'm not super confident that I would be able to review it soon. 21:29:58 ok, so since people have a really busy week coming up, i'm guessing that doesn't mean a lot of time before G-1 21:30:02 * salv-orlando Probably half... 21:30:07 I'd guess then we move it to G-2 21:30:16 I don't think there's a big practical impact on anyone? 21:30:20 nicira 21:30:22 nope 21:30:25 oops** 21:30:31 Sorry my office network get down. I'm back now 21:30:32 arosen: wrong window? 21:30:37 yea :/ 21:30:39 i hope that wasn't a password :P 21:31:13 Lol 21:31:22 ok, updated to be G-2 21:31:28 if it merges in G-1, all the better 21:31:36 but ttx wants us to be conservative with targeting milestones 21:31:51 https://review.openstack.org/#/c/15872/ 21:31:57 some simple L3 validation improvements 21:32:02 just needs 2nd core 21:32:16 i will check it. 21:32:35 amotoki: thx 21:32:44 https://review.openstack.org/#/c/15384/ 21:32:45 pagination 21:32:50 anyone have the status on this? 21:32:58 seems like there are some design questions in the reivew 21:33:02 hi 21:33:14 alex has sent out some emails about it. 21:33:33 danwent: yes. Alex Xu has come up with a POC patch for dealing with the issue highlighted on the plugin interface side 21:33:36 I think salv-orlando has some opinion on it. 21:33:38 That's for me to review 21:33:54 gongysh: I am checking his email. On API side his proposal is reasonable. 21:33:58 Ok… sounds like something that is not high propbability for G-1? 21:34:05 My concern was not on the tenant API side. But on the plugin interface. 21:34:08 or do we think design questions may be wrapped up in the next day or two? 21:34:20 its a big patch :( 21:34:21 I'd say that it's not a big deal if this slips for G-3 21:34:25 G-2 sorry :) 21:34:33 though a fair amount is test code 21:34:47 Since it is a big patch I also expect more cycles to fix minor issues which have not yet been spotted 21:34:54 also, it touches all the plugins 21:35:04 yeah, good point 21:35:06 salv-orlando: yea makes sense 21:35:10 ok, let's move to G-2. 21:35:26 fine with that. 21:35:26 it will probably take us a week to sort out the design and reivew, at which point, g-2 will be open for merging 21:35:30 gongysh: thx 21:36:09 ok, updated whiteboard 21:36:40 are there any other outstanding reviews where we think it is important that the changes land in time for G-1? 21:36:47 particularly, if there are changes relevant to stable/folsom 21:37:08 also, are there any bugs targeted at G-1 that seem relevant to stable/folsom, but are not "in progress": https://launchpad.net/quantum/+milestone/grizzly-1 21:37:34 rkukura: https://bugs.launchpad.net/quantum/+bug/1067669 ? 21:37:35 Launchpad bug 1067669 in quantum "Mapping same bridge to different phyiscal networks succeed" [Medium,Confirmed] 21:37:59 markmcclain: https://bugs.launchpad.net/bugs/1070011 ? 21:38:00 Launchpad bug 1070011 in quantum "the notification message payload for delete events should include all metadata" [Medium,Confirmed] 21:38:00 I'll get a fix into review for that in the next day or two 21:38:20 garyk: I assume this does not need to be G-1 anymore? https://bugs.launchpad.net/bugs/1046766 21:38:21 https://bugs.launchpad.net/quantum/+bugs?field.tag=folsom-backport-potential 21:38:21 Launchpad bug 1046766 in quantum "Need to provide a formal API for Nova to use to plug/unplug VIFs" [High,In progress] 21:38:35 rkukura: k, great. when you start working on it, please move it to "in progress" 21:38:38 yeah.. I planning to get that one pushed in time 21:38:40 ok 21:38:47 the ceilometer folks need it 21:38:56 markmcclain: k, thanks. 21:38:58 danwent: there are 2 patches pendning review for linuxbridge and nova. 21:39:08 garyk: in quantum or in nova? 21:39:31 danwent: in both. they are linked together. 21:39:40 ok, links? 21:40:09 danwent: it would be best to get it pushed fr nova and then we can commit the quantum. what i mean is that if the one goes through without the other then linuxbridge will not work. 21:40:31 garyk: yeah, makes sense to push nova first, as we have more control of quantum. 21:40:34 we can do itin a staged manner but it will take weeks for something that is rarely if not used at the moment 21:40:41 is the quantum bug targeted for g-1 already? 21:40:51 yes 21:41:21 https://review.openstack.org/#/c/14830/ and https://review.openstack.org/#/c/14961/. 21:41:27 the patter is the quantum patch 21:41:34 sorry latter 21:41:40 garyk: I think is should be a BP rather than a bug. 21:41:56 amotoki: the bp will be done for g-2 21:42:29 garyk: do we need to prevent the quantum side from being merged before the nova side? if so, I would -2 it yourself, to prevent accidental merger. 21:42:41 danwent: good point. i'll do that 21:42:57 Ok, so sounds like we basically have our marching orders for G-1 21:43:04 any additional elements we want to highlight? 21:43:23 items at medium priority or below, its up to the developer to track down core devs to get them reviewed. 21:43:30 danwent: there is the issue with qpid - i have a patch in common at the moment which deals with it 21:43:35 garyk: I feel it is the first step of your plan and the bug seems not be be all resolved by your patch? 21:44:28 garyk: yeah, I saw that. patch looks reasonable to me, but I don't have core privs in openstack-common, nor do I know qpid well enough to say with confidence that its ok. 21:44:45 garyk: do we have other who will approve that patch, or do we need to go bug people? 21:44:49 amotoki: the bug should be the bp. 21:45:08 danwent: i think that we should be ok. if there is no reviews in a daythen i'll let you know 21:45:22 garyk: k, great. and no corresponding quantum change needed? 21:45:33 Ok, last call for any G-1 topics 21:45:44 danwent: no. it is all in common. just need to pul i the code when it is approved. 21:45:50 #topic sub-teams 21:46:02 amotoki: i'll open a bug for the lb 21:46:18 So as we talked about at the summit and in previous meetings, we are trying to distribute quantum leadership tasks better by making subteams 21:46:20 danwent: stable need a stiff drink 21:46:35 danwent: What is the wiki for the sub-team? 21:46:51 magana: was an etherpad right? 21:46:52 i transferred the state of the etherpad to a wiki, which looks WAY more official: http://wiki.openstack.org/Quantum/Teams 21:47:04 from the summit 21:47:04 ah ok 21:47:15 yeah, it was: https://etherpad.openstack.org/grizzly-quantum-wrapup 21:47:28 but please don't edit that page anymore, otherwise they will get out of sync 21:47:44 anyway, i'm going to start assigning the "approver" field of blueprints to be the sub-team lead, not me 21:47:49 danwent: got it, thanks! 21:48:24 that sub-team lead will be responsible for understanding the state of those items before the team meeting, making sure their 'delivery' state gets updated, etc. 21:48:29 basically, distributed nagging :P 21:49:16 also, for bugs, I suggested a set of tags. Thus, when we do bug triage, we can tag bugs with a particular sub-team tag, and then add at least the sub-team lead as a "watcher" on the bug. 21:49:34 as the sub-team lead should be best equipped to triage the bug 21:49:56 danwent: agreed i think there are a ton projects now. make the team name the tag/keyword? 21:50:32 *of teams 21:50:33 sthakkar: ? that's basically what I tried to suggest, or maybe i'm not following? 21:50:39 http://wiki.openstack.org/Quantum/Teams 21:51:21 danwent: oh yea, im in agreement 21:51:26 in some cases, the team is more responsible for quantum items in another project, in which case, perhaps we tag the items with 'quantum' to identify that it is a Horizon bug related to quantum. 21:51:40 ok… so all of this is open to feedback and revision, but we have to start somewhere. 21:51:41 wasnt sure if the bug system allowed the complex team names we currently have 21:51:50 w/ spaces etc 21:52:05 so if you're a sub-team lead, please be ready to "report" on the status of your sub-team at the quantum monday meetings. 21:52:18 im happy to take point on lb 21:52:21 danwent: I can take care of the lb&ovs plugins, so you can remove the question marks 21:52:24 also, I didn't have anyone official to put in charge of the OVS + LB plugin 21:52:37 rkukura: let me know if you're interested, otherwise perhaps someone else. 21:53:31 sthakkar: i was leaving that one as TBD, as I wanted to see who ended up contributing much of the code and showing up at monday meetings. I'm happy to have you play that role at least in the interrim though, though I'd also like to make sure the mirantis folks participate as well. 21:53:32 danwent: "lbaas" is a better tag for LBaaS. "lb" is confusing in quantum community. 21:53:39 amotoki: good point 21:53:44 will update 21:54:11 amotoki: i even typed it twice for two different things :P 21:54:13 danwent: ok sounds good, im fine with that. just volunteering to be lead nagger :) 21:54:23 sthakkar: ok, sounds good. 21:54:25 * salv-orlando is developing a form of hate toward was suffix 21:54:28 aas 21:54:40 yeah.... 21:54:51 #topic open discussion 21:54:53 salv-orlando: haha 21:54:53 I have two items 21:54:56 first. 21:54:58 salv-orlando: :) 21:55:05 memory consumption by unit tests 21:55:18 garyk has been putting a lot of work into this, but its proven pretty intractable 21:55:23 I've been working on it too 21:55:30 would be good if someone else could take a crack 21:55:37 markmcclain: ok, great 21:55:44 markmcclain: any leads? 21:55:50 danwent, markmcclain, garyk: I am the third volunteer 21:56:02 three is a crowd :) 21:56:30 ok, well i'm sure garyk is happy to have one of you assign the bug to yourself, and we can all coordinate on possible solutions 21:56:32 danwent: i am sorry but i could not resist - http://www.youtube.com/watch?v=v7acD4q0lp0 21:56:37 https://bugs.launchpad.net/bugs/1065276 21:56:39 Launchpad bug 1065276 in quantum "Quantum test suite leaks memory like a sieve" [High,Confirmed] 21:56:55 garyk: ha! 21:57:12 garyk: man, its been forever since i've seen that 21:57:20 they've got us working in shifts! 21:57:28 anyway 21:57:35 other open discussion topic 21:57:45 https://review.openstack.org/#/c/15771/ 21:57:56 this is mokeypatch change for openssl zombies 21:58:12 danwent: this in a intesrting one. 21:58:15 we merged this change into master, but someone raised concern with it during stable/folsom review 21:58:55 garyk: has eventlet even merged the change upstream yet? 21:59:02 danwent: the correct solution is to fix eventlet. i understand tat this has been done for fedora. it just needs to be done for ubuntu. 21:59:04 or are they talking about patching upstream eventlet? 21:59:27 i.e., is there a released version of eventlet that can fix this? 21:59:38 danwent: i am not really sure. i'll try and get oneof the canonical guys. nce we have an ack from them then we can remove the ugly patch for os=False 22:00:23 danwent: the correct solution is to patch eventlet to treat this specific case. i think that it still needs to be tested. 22:00:24 salv-orlando: do let me know if I can help in coding on https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper ...will like to get involved in implementation of it 22:00:37 garyk: yeah, that is my feeling as well. My first priority is making sure that running Folsom installs don't have this issue though, so until we can confirm that both RH and Ubuntu are fixed, i'm in favor of keeping the change. 22:00:49 danwent: me too. 22:00:55 Chinmay_: for this patch I can use your help as a reviewer, but we'll definitely need impl help for the G-2 work 22:00:57 chinmay: yep mentioned that to salvatore 22:01:02 Chinmay_: thats was implemented for cisco plugin only 22:01:25 #todo #garyk followup with canonical about eventlet patch for zombies bug 22:01:26 magana: assuming he was referring to the one currently in g1/g2 that salvatore is leading 22:01:29 salv-orlando: sure i can help you out with review 22:01:36 salvatore is working on the general service type framework 22:01:36 danwent: ok 22:01:38 k thanks 22:01:46 garyk: ok, let's sync up again about it next meeting, so we can figure out whether we need to push that to stable or not 22:01:47 and for implementaiton for G2 ...i can get involved form the start 22:01:58 danwent: ok 22:01:59 having it in master for the time being is OK in my opinion 22:02:05 ok, other open discussion? 22:02:21 otherwise we should let garyk go to bed :( 22:02:32 :) good night 22:02:47 ok, thanks folks. remember to focus on high priority reviews for your review days! 22:02:51 #endmeeting