21:02:45 #startmeeting Networking 21:02:46 Meeting started Mon Aug 12 21:02:45 2013 UTC and is due to finish in 60 minutes. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:49 The meeting name has been set to 'networking' 21:02:52 #link https://wiki.openstack.org/wiki/Network/Meetings 21:03:11 #topic Announcements 21:03:32 #info arosen is now a member of the stable team 21:03:42 yay! 21:04:32 Will definitely be nice to increase our review bandwidth there. 21:05:03 Yup :) 21:05:51 The Havana Feature Proposal Freeze is 11 days away. Any approve blueprint that does not have code proposed by then will not make the Havana. 21:06:35 #topic Bugs 21:07:29 Last week was a bit of a bumpy right getting items approved and merged through the gate. We had several critical items pop up 21:07:45 and solved most of the them. The lone exception is this one: 21:07:45 https://bugs.launchpad.net/neutron/+bug/1210664 21:07:48 Launchpad bug 1210664 in neutron "neutron can't setup basic network connnectivity in gate jobs" [Critical,Confirmed] 21:08:04 Currently, tempest skips this test. I know marun has been looking into it 21:08:35 Another important bug changes the way the db schema is created: 21:08:36 https://bugs.launchpad.net/devstack/+bug/1207402 21:08:37 Launchpad bug 1207402 in neutron "neutron should automatically stamp the database version when it is deployed" [High,In progress] 21:09:01 I am keeping the patches in WIP at the moment 21:09:25 salv-orlando is working on this, so if there are problems switching from auto creation to running migrations like the other integrated projects please let the team know 21:09:37 I've heard from nati-ueno that removal of DB_ENGINE global breaks metaplugin, so I want to make sure no plugin is broken before really proposing theam 21:09:41 * them 21:10:01 salv-orlando: makes sense 21:10:26 One more thing is that if you're not sure your plugin fully leverages migrations, this is the time to do so. 21:10:35 emagana already did this for the plum grid plugin 21:11:47 if somebody is interested, this is the patch: https://review.openstack.org/#/c/41005/ 21:13:16 emagana: looks like you've been unlucky with merge conflicts.. hopefully the third time will be the last 21:13:28 Any bugs the team needs to discuss? 21:13:50 #topic Docs 21:14:04 Nothing new about Docs, working on some cleaning 21:14:24 We have 3 major categories of new docs we're tracking: VPN, Firewall and ML2 21:14:42 nati_ueno and sumitNaiksatam working on FwaaS and VNPaaS 21:14:52 rkukura: I assigned you to the ML2 doc bug, but feel free to reassign to someone on the ml2 subteam 21:14:58 hi! sorry late 21:15:03 markmcclain: ok 21:15:35 nati_ueno: np. We've assigned you 1 bug for each minute you've been late :p 21:16:36 salv-orlando: ha ha 21:17:14 Any other doc items? 21:17:24 nothing from my side! 21:17:51 markmcclain: for fwaas, i would prefer to put the admin patch after the driver patch gets approved 21:18:16 SumitNaiksatam: ok 21:18:20 similarly for the API patch, i would prefer to get confirmation on the commit operation 21:18:57 driver patch I believe is very close - we can discuss in the FWaaS section 21:19:13 ok.. I wanted to discuss commit during the FWaaS report 21:19:28 #topic Stable 21:19:40 moving up because garyk has a conflict at the bottom of the hour 21:19:55 #link http://tarballs.openstack.org/neutron/quantum-2013.1.3.tar.gz 21:20:12 garyk: Anything else to add? 21:21:11 last week the stable grizzly branch was release 21:21:18 Ok looks like he's left 21:21:32 oops.. you're still around :) 21:21:39 nothing else much to add. guess we need to start to work on the new backports now 21:21:55 yeah, sorry i am preparing a list of the open nova reviews regarding neutron 21:22:09 but nothing imporant to add regarding the stable. sorry 21:23:02 VPNaaS API doc is almost ready to review. 21:23:11 Yeah.. the week after a stable release is always quiet 21:23:20 #topic Nova 21:23:39 there are quite a lot of open reviews - would be nice if other can also jump in: 21:23:54 https://review.openstack.org/#/c/31061/ 21:24:19 https://review.openstack.org/#/c/38803/ - i think that this will not work as the default device_id is '' 21:24:22 yep 21:24:31 https://review.openstack.org/#/c/36138/ 21:24:46 and last but not least: https://review.openstack.org/#/c/40561/ 21:25:46 if others can take a look it would be great. thanks 21:26:32 Thanks for sharing these 21:27:30 Any other nova questions? 21:27:54 wondering if I can get some help with test_neutronv2.py 21:28:23 dkehn: sure. i can help you offline if you wnat 21:28:36 garyk, that would be great 21:29:04 #topic API 21:29:11 salv-orlando: hi 21:29:12 hellp 21:29:23 hello - nothing major to report. 21:29:26 i am going to call it a night. sorry guys. 21:29:37 oh I thought things were melting down on the API side :) 21:29:52 garyk: bye 21:29:53 is there something I don't know? 21:30:02 I am melting down, but this is an unrelated matter 21:30:14 or perhaps something I forgot because of the late hour 21:30:17 haha.. I thought there was something I didn't know 21:30:38 #topic VPN 21:30:40 no everything is quiet luckily 21:31:20 yes.. always nice when the API is quiet at the end of h3 21:31:37 OK ipsec driver is still in review. 21:31:59 In this week, I posed status update code https://review.openstack.org/#/c/40993/ (WIP) 21:32:06 ok.. I see if was updated Friday.. I'll checkout the new code 21:32:18 I'm also working on supporting service type framework 21:32:20 markmcclain: Thanks 21:32:29 client patch is still in review 21:32:34 That's all from me 21:32:55 nati_ueno: thanks for updating 21:33:07 #topic LBaaS 21:33:25 hi. nothing much changed from last week 21:33:39 looks like 2 patches in review at the moment 21:33:43 support for service type framework review got +2 from nati_ueno 21:34:41 this one is to be reviewed https://review.openstack.org/#/c/40381/ 21:35:20 today I've posted https://review.openstack.org/#/c/41396/ as a first step towards more flexible vip-pool relationship 21:35:48 probably that's all significant code for lbaas in H-3 21:36:00 and that's all from my side for today 21:36:05 great thanks for getting it in early! 21:36:19 #topic FWaaS 21:36:28 hi 21:36:33 Agent patch was merged today, thanks to SridarK for putting in work on this patch 21:36:42 So the iptables driver is that is left correct? 21:36:44 CLI patch was merged last week, thanks to KC 21:36:56 markmcclain: yeah, driver is left 21:37:06 https://review.openstack.org/#/c/34074 21:37:14 its pretty close, already has Salvatore's blessing (and Armando's +1) 21:37:23 anyone else has any thoughts/objections on this patch? 21:37:33 RajeshMohan is here 21:37:34 I'm btw 21:37:38 sorry I'm late :) 21:37:51 I am here Sumit 21:37:55 SumitNaiksatam: I'll re-review today 21:38:02 I believe RajeshMohan will be doing a rebase shortly 21:38:06 nati_ueno: thanks 21:38:07 I think Armando's +1 should be read as a -1 with the caveat that you can improve exception handling in another patch 21:38:27 My rebase will be in soon 21:38:50 yeah…I think if we can improve the exception handling I'd be a happy bunny :) 21:39:09 armax, salv-orlando: it will be good to point out what exactly is expected 21:39:44 I really don't know that :) Perhaps RajeshMohan has a better idea 21:39:46 i think the current model is preserving the abstraction between the driver and the agent 21:40:18 I can check with Armando to understand what he expects 21:40:19 As currently written I'm −1 21:40:33 yeah…let's take this offline 21:40:45 I 21:40:45 LOG.error and then converting the exception to a string loses lots of context 21:40:54 Since driver will be vendor specific, we did not want to pass those exceptions to agent 21:40:55 am around after the call if 21:41:02 I can be of help 21:41:05 I'll add my comments to the review 21:41:17 The horizon patch is complete but is waiting on Akihiro (who is on vacation) and also needs one more Horizon core 21:41:33 I pushed the patch for the "explicit commit operation" yesterday night - https://review.openstack.org/#/c/41353/ 21:41:49 this has a little more work to do on the plugin side (which I should be able to complete by today), but from an API perspective it has everything to give you a feel for what we are doing, would appreciate your feedback 21:42:00 Aaron, I did not see your email earlier, but I have responded to it a couple of hours back 21:42:28 I think we mentioned the ability of doing a bulk create several times doing the API patch review. 21:42:48 Sumit, can you refresh my mind on why we did not follow that route but preferred a two step process? 21:43:09 salv-orlando: bulk create is different from the requirement for commit 21:43:36 salv-orlando: i also don't recall discuss this to the extent of several times 21:44:05 sorry several times for me is >1 21:44:49 the two step process is the approach we have followed from day one (even while discussing the in the summit) to allow policy auditing 21:45:02 bulk operations are kind of complementary to this discussion 21:45:44 but different 21:46:42 ok, perhaps the discussion on bulk operations derails from the focus of the topic 21:46:59 I'll need to look at the implementation 21:47:09 salv-orlando: yeah, i think we can have bulk operations regardless but those will be on the rules/policies 21:47:25 but I had a few concerns over agent restarts and which version of the policy actually gets applied 21:47:32 I don't know if anybody has an opinion on committing rules with an explicit action. As already said, I am not a big fan of it, but since I understand the need for it, and I don't have a better alternative, I will accept it. 21:47:45 Or I will reserve the right to look at the implementation as markmcclain said 21:47:59 markmcclain: that part will be handled in the implementation 21:48:18 I have concern about consistency of API model. 21:48:33 markmcclain, salv-orlando: essentially we will follow the current model of pending states 21:48:39 if all resources will have commit mode, it sounds big change.. 21:48:52 yup, but i guess you need to save 'committed' and 'desired' state for each rule 21:48:52 because current implemenation looks have additional pending change table 21:49:12 nati_ueno: why should all resources have commit mode? 21:49:39 SumitNaiksatam: because needs for commit operation is generic one 21:49:41 for other resources policy is not separate from their own state 21:50:02 this is kind of different for the firewall model 21:50:22 Ok looks like there is more to discuss, so let's look at the code: https://review.openstack.org/#/c/41353/ 21:50:32 gotcha 21:50:35 markmcclain: sure 21:50:40 and then follow-up on the ML for concerns about the big picture 21:50:54 and in the review if there are code specific items 21:51:01 I'm also not clear why all resources would have a commit mode. I think only firewalls require a commit to allow policies to be applied to firewalls one firewall at a time. 21:51:30 dflorea: thats correct 21:51:47 SumitNaiksatam: dflorea: I'll post my comment in the mailing list, so let's continue 21:51:48 we have a model where one policy can be associated with multiple firewalls 21:52:01 SumitNaiksatam: dflorea: I'll post my comment in the mailing list, so let's continue on there 21:52:09 current model of implicit commit does not lend well to that 21:52:17 yeah.. we're running short on time 21:52:27 Any other FWaaS items/ 21:52:28 ? 21:52:31 yeah, sure i am done with the update on the fwwas 21:52:39 thanks for all the reviews 21:52:39 #topic ML2 21:52:44 rkukura: hi 21:52:49 hi 21:52:54 nothing major to report 21:53:05 devstack support for ml2 has been improved 21:53:12 was going to ask about it 21:53:32 various mechanism drivers and portbinding BPs under development 21:53:54 once the gating is stable, should we think about adding ml2 to the gating? 21:54:41 right now it is the default config which is OVS 21:55:02 so I think the next logical step for deprecation is making the ml2+ovs the default in devstack 21:55:20 should we start gating on it before switching default? 21:55:54 I think that would make sense to be the least disruptive 21:56:08 we can talk offline the CI folks for their feedback on that plan 21:56:11 rkukura: That's possible, so may be we need to discuss with it with clarkb or jeblair 21:56:18 OK 21:56:23 Anything else? 21:56:34 not that I can think of - anyone else? 21:56:54 #topic Horizon 21:57:25 amotoki is traveling this week, but has updated Horizon report on the agenda 21:57:33 #topic Open Discussion 21:57:42 I have a quick question... For VPNaaS API doc review, should I just do std gerrit review (diffs are hard to review), or also create a PDF for early review rounds? 21:57:44 I've updated the embrane's plugin patch, it'll appreciate some love :) : https://review.openstack.org/#/c/38222/ 21:58:20 pcm_: review is enough :) 21:58:26 I wanted to schedule a discussion around the policy and ipam blueprint we submitted at juniper-plugin-with-extensions 21:58:32 for open discussion: would be nice to see this in H-3: https://blueprints.launchpad.net/neutron/+spec/multi-workers-for-api-server 21:58:33 pcm_: we can build the pdfs from the patch under review 21:58:35 pcm_: standard gerrit review is fine 21:58:38 nati_ueno: Just wondering what's easies to read. 21:58:42 ok 21:58:47 would a discussion in ML be better or do we need an IRC meeting to discuss? 21:58:58 pcm_: yeah, generating pdf is quite easy if it is on review 21:59:13 pcm_: but commenting is hard in the pdf 21:59:28 nati_ueno: roger that. Will Gerrit 21:59:47 jakemccann: I would be happy to assist with that review, but I would like to hear from somebody else from the community whether it's ok to have this kind of change in the last milestone of the release cycle 21:59:55 multi-workers-for-api-server has code up for review 22:00:31 jackmccann: see above (sorry I mistype your nick) 22:00:48 salv-orlando: thanks, would be nice to have thoughts from core on which direction to take 22:00:54 I see the benefit.. my biggest concern at this point is stability 22:01:06 I think the direction is fine. My concern is stability. 22:01:07 and the amount of time left to test 22:01:09 Sorry mark 22:01:20 https://review.openstack.org/#/c/37131 based on glance (we've been running since May) 22:01:35 jackmccann: is that func can be optional function by conf 22:01:36 https://review.openstack.org/#/c/36487/ using openstack/common/service.py 22:02:01 yes, it is optional, set number of workers to zero in conf (would be default, no change in current behavior) 22:02:43 salv-orlando will follow-up with you folks offline 22:02:54 jackmccann: sounds good 22:03:17 salv-orlando: I'm +1 for this bp in H3, I'm also happy to assist the review 22:03:29 Any other items for discussion? 22:05:36 Ok.. We've got 11 days left before the freeze and other projects have deadlines around the same time next week 22:06:10 so expect that the time the CI systems to evaluate could be longer if there are lots of pending reviews (which always happens during H3) 22:06:26 Have a good week 22:06:29 #endmeeting