18:40:55 #startmeeting Networking FWaaS 18:40:56 Meeting started Wed Jun 25 18:40:55 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:40:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:40:59 The meeting name has been set to 'networking_fwaas' 18:41:05 #info agenda https://wiki.openstack.org/wiki/Meetings/FWaaS 18:41:18 #topic Action Item follow up 18:41:35 #link https://wiki.openstack.org/wiki/Meetings/FWaaS#Action_items_from_previous_meeting 18:41:50 beyounn: have we sent the DVR related email to the mailer? 18:41:59 no, I did not 18:42:10 * SumitNaiksatam thinks whether its past its relevance to send it now 18:42:26 beyounn: last week you mentioned you were going to, any blockers? 18:42:27 Ok, I will do 18:42:57 beyounn: we want this to be on record 18:43:00 The issues is that I don't have a idea on the direction for this 18:43:12 beyounn: that we have identified the issues 18:43:17 beyounn: thats fine 18:43:30 beyounn: the expectation is not necessarily that you provide you a solution 18:43:35 I throw it out, only makes open end problem, anyway, I will do it 18:43:49 beyounn: identifying and raising the issue is the first step 18:43:57 OK 18:44:36 SridarK: were you able to check with the owner of https://bugs.launchpad.net/neutron/+bug/1323299? 18:44:57 oh wait i put a comment here 18:45:04 SumitNaiksatam: no since i saw that u have updated the bug that this is expected behaviour 18:45:09 SumitNaiksatam: yes 18:45:16 SridarK: ok 18:45:28 so this can be closed i think ? 18:45:52 SridarK: lets wait for him to come back 18:46:00 ok 18:46:13 SridarK: i think we can certainly have a discussion on how we can extend to this functionality 18:46:22 SridarK: right? 18:46:30 yes 18:46:38 SridarK: i guess you are asking if the AI can be closed? 18:46:52 SridarK: if so yes, lets just keep an eye if the author comes back 18:46:54 actually i was asking about the bug 18:46:59 but i see ur point 18:47:00 SridarK: ah 18:47:07 SridarK: what about following up with #link https://review.openstack.org/#/c/90575/ 18:47:22 i am not able to locate his coordinates 18:47:31 Yes i have discussed with SridharGaddam 18:47:39 SridarK: ah cool 18:47:49 He has responed to Mark's comments and waiting response 18:47:58 I requested him to ping him on IRC 18:48:06 SridarK: but the last response is June 5th 18:48:16 He will follow up - 18:48:18 SridarK: i did bring this up with markmcclain in the neutron IRC 18:48:35 SridarK: i think we should try and get them together 18:48:42 SridarK: but you have a -1 as well on this 18:48:42 I also asked him to join the mtg today - is bit late for SridharG 18:49:05 SridarK: are your concerns addressed? 18:49:12 SumitNaiksatam: yes - my issue which was earlier is on the same line of composing plugin on agent 18:49:26 but i am not sure on the right approach 18:49:50 Mark pretty much put the -2 for this i believe 18:49:58 SridarK: so do you plan to remove the -1 or keep it? 18:50:39 I think if it is okay to take this approach - then i can add some more things that can be done 18:51:07 but if this approach is itself wrong then we need to abandon or take a diff approach 18:51:08 garyduan beyounn: have you looked at this? 18:51:22 perhaps we can discuss this more as well 18:51:32 i had looked at this earlier, but i have lost a bit of context on it since 18:51:46 will send u an email 18:51:59 and we can discuss more amongst the team 18:52:10 yes 18:52:44 my concern was loading composing the plugin in the agent side 18:53:00 *composing 18:53:03 SridarK: you seemed to have asked for UTs as well 18:53:13 yes minor issue on the UT 18:53:39 #action SridarK to start an email thread with FWaaS team and SridharGaddam regarding https://review.openstack.org/#/c/90575 18:53:55 I think if we can conclude that this approach is fine - i am good - i will point him to a few more checks that can be added 18:53:55 SridarK: lets try to close on this 18:53:59 ok will do 18:54:10 The proposed fix is good to have, right? 18:54:20 but not that critical 18:54:24 garyduan: please weigh in as well, i have added you as reviewer 18:54:34 SridarK: you can add markmcclain to the thread as well 18:54:39 ok 18:54:43 Ok 18:55:21 SridarK: next AI for you again, how is the bug triage coming along? 18:55:29 All bugs triaged 18:55:43 SridarK: ah ok 18:55:46 I don't have rights to mark it as Triaged 18:55:57 SridarK: oh 18:56:01 SumitNaiksatam: perhaps only u can do it 18:56:12 SridarK: ok i can follow up on that 18:56:21 SridarK: whats the best way to sync up? 18:56:25 ok there were only 2 that needed action 18:56:29 SridarK: i want to minimize the effort on your end 18:56:40 i have added comments to the bugs 18:56:47 SridarK: ok 18:56:50 SumitNaiksatam: i can send u an email 18:57:14 SridarK: alright great, thanks much! 18:57:16 and u can mark it Triaged or if i can be given rights i can do so 18:57:25 np 18:57:37 SumitNaiksatam: we can sync up offline 18:57:53 SridarK: unfortunately i dont have the admin rights to any of this, i am just as much of a foot soldier :-) 18:58:03 SumitNaiksatam: :-) 18:58:21 It says u need to be "Bug Supervisor" 18:58:28 whatever that means :-) 18:58:49 SridarK: perhaps part of the cavalry :-P 18:58:55 not a big deal - i will push u a list and u can mark it so 18:58:57 :-) 18:59:13 SridarK: regarding the router delete 18:59:32 i noticed that there was a similar bug for VPNaaS about deleting interfaces 18:59:37 SumitNaiksatam: yes that has been updated on the associated bug 18:59:50 SumitNaiksatam: as we discussed last week 18:59:54 and out there they are taking the approach that they are not allowing the interface delete 19:00:08 SridarK: yeah, should we follow that approach as well? 19:00:16 SumitNaiksatam: i think we will do the same with service insertion patch 19:00:17 this is question for all 19:00:33 not allow interface or router delete if firewall is associated? 19:00:54 SumitNaiksatam: as we will now track the router in the plugin db 19:00:55 I agree 19:00:58 but perhaps its different for firewall, since it will temporarily open up a security hole 19:01:16 SridarK garyduan: see my last comment ^^^ 19:01:27 SumitNaiksatam: that makes sense too 19:01:44 SumitNaiksatam: yes 19:01:47 then should we update firewall state? 19:02:12 garyduan: but then it does not solve the problem 19:02:20 garyduan: that gets tricky on the "all routers in tenant" scenario 19:02:56 SridarK: perhaps we have to wait fall back to the service insertion related fix 19:03:02 Why do we have PENDING state associated with if there is a router or not? 19:03:12 SumitNaiksatam: my feeling too as it is a lot cleaner 19:03:13 SridarK: and let anyone who wants to fix it in the interim do it, if they want to 19:03:32 SumitNaiksatam: yes so left the bug unassigned as we discussed 19:03:43 garyduan: PENDING is when an operation is in process 19:03:54 can we see if firewall is pushed to agent, we mark it as active? 19:04:03 see=say 19:04:10 garyduan: i dont think its proper to move a firewall from ACTIVE to PENDING if the router is deleted, is it? 19:04:38 SumitNaiksatam: I agree 19:04:42 esp if there are other routers in the tenant 19:04:55 we need to do it for last router in the tenant 19:04:56 SumitNaiksatam: but people might ask question about consistency 19:05:13 so why don't we mark it as active when fw is created without router 19:05:51 garyduan: definitely not that 19:05:59 garyduan: as there is no router it really cannot be active 19:06:16 I am totally ok with that 19:06:16 garyduan: you can make a case for moving it to PENDING when the router is deleted 19:06:27 I am just thinking that people might ask questions 19:07:09 garyduan: can you elaborate on the question that people might ask? 19:07:18 garyduan: sorry i must have missed it 19:07:31 SumitNaiksatam: garyduan yes that case of router delete - is valid - but we almost would need to say that is PENDING_DELETE on that router but it is still active on other routers 19:07:32 when fw is created without router, it's pending 19:07:46 when the only router that fw uses is deleted, it's active 19:07:54 that's not consistent 19:08:19 SridarK also raised a question, which is if fw is applied on multiple router 19:08:26 we have to track them 19:08:35 to maintain the firewall state 19:08:59 garyduan: yes that is a problem for sure - but we don't track them as we were always looking at insertion to get away from the model of all routers on tenant 19:09:08 garyduan: that is the problem that we are trying to solve 19:09:28 garyduan: we know that it is inconsistent, no argument on that :-) 19:09:40 I think we can solve that problem but will require some cycles and this will get solved with insertion so why not just wait for that 19:09:57 I agree. If we do want to have PENDING state, then some cleanup need to be done 19:09:57 and solve this issue in that context 19:10:09 garyduan: just whether we should fix it now (and the fix is kind of intensive) or wait for the service insertion to come through so taht we can do it in an elegant way 19:10:25 I'd say wait for service insertion 19:10:28 SridarK: yeah, basically repeating what SridarK said 19:10:34 garyduan: exactly 19:10:42 garyduan: so we are all on the same page :-) 19:10:46 so it is documented to that effect on the bug 19:10:47 always 19:12:29 so we will just leave this as is for now 19:12:43 agree 19:12:59 ok moving on 19:13:21 the AI was beyounn badveli to decide if they can look at hit counts 19:13:28 however i think we discussed this 19:13:33 and we are not looking at this now 19:13:39 or rather immediately 19:13:47 SumitNaiksatam: on that point prad_ was quite interested in this 19:14:20 I did tell him that in terms of resources - both dev and review - it was decided that it is tight 19:14:37 SridarK: we can help him in any way he needs help 19:15:05 SumitNaiksatam: yes for sure - we will defn get the lifecycle metrics 19:15:42 and on hit counts lets see how it goes if beyounn and badveli have time constraints 19:16:22 but clearly he indicated that it is high on his priority list 19:16:31 ok 19:16:43 SridarK: please convey to prad_ that we are willing to help him if he is ready to take the lead on this 19:16:54 SridarK: by we, i mean the entire team here 19:16:55 SumitNaiksatam: will do 19:16:56 Sridark, we will try to help as much as we can 19:17:05 beyounn: great, ye 19:17:14 ok got it thanks SumitNaiksatam beyounn 19:17:28 i can also propose that, if it comes to that, we can all have a day long hackathon with prad_ at the other end 19:17:35 and just walk him through 19:17:48 SumitNaiksatam: sure i think that will be great 19:17:56 ya 19:18:37 SridarK: so basically let prad_ propose this and we will be happy to participate (i take the liberty of speaking on behalf of the entire team) 19:18:57 SridarK: we can try and request Rajesh as well, perhaps buy him a lunch first ;-) 19:18:58 I will also check with RajeshM on the feasibility and to see if we can get some guidance 19:19:08 SumitNaiksatam: on the same page :-) 19:19:16 SridarK: :-) 19:19:21 ok we are going slow today 19:19:28 we still have one more AI 19:19:56 if we do decide to do the hit counts, i would like to see a spec in review at the earliest (on the neutron side) 19:20:06 this is an AI for prad_ possibly 19:20:15 SumitNaiksatam: will convey 19:20:21 SridarK: thanks 19:20:25 #topic Bugs 19:20:34 ok i think we already covered most of this 19:20:42 SridarK: anything that we did not cover? 19:20:52 SumitNaiksatam: no we are good 19:21:10 ok 19:21:18 #topic blueprint tracking 19:21:36 service objects #link https://review.openstack.org/#/c/94133 19:21:39 beyounn: ? 19:21:47 yes 19:22:07 I have sent email to Kyle nachi and others 19:22:15 but I did not get any activities from them 19:22:43 Vashnu helped me to update the db migration script, I'm about to wake up my code review 19:23:02 That is all for me 19:24:02 BTW-- since I have updated spec based on our last discussion, I hope everyone can also do a recheck, just in case I missed anything 19:24:11 beyounn: yes 19:24:13 beyounn: will do 19:24:15 beyounn: thanks 19:24:21 Thanks all 19:24:30 will do 19:24:48 beyounn: since we did not get a response from nati_ueno amotoki, perhaps better to follow up further 19:25:17 Yes, I will send email this friday (once a week) 19:25:24 #action beyounn to follow up with nati_ueno and amotoki, request them to review #link https://review.openstack.org/#/c/94133 19:25:34 I hope they are not mad at me :-) 19:25:43 beyounn: perhaps trying to catch them on IRC will be more helpful 19:25:53 beyounn: i will respond to the email thread 19:26:04 Sumit: thanks 19:26:14 #action SumitNaiksatam to respond to beyounn’s email thread on service objects review 19:26:37 #topic vendor blueprints 19:26:42 SridarK: anything to discuss here? 19:27:34 SumitNaiksatam: nothing - working with our group to get a review up 19:27:52 SridarK: ok thanks 19:27:57 #topic open discussion 19:28:10 we plan to have a single spec to address plugin and agent/driver 19:28:12 beyounn: i noticed you sent the email about DVR 19:28:18 SridarK: ok 19:28:21 and have separate patches referring to the same BP 19:28:33 SridarK: single spec is fine, perhaps patches need to be separate 19:28:41 SridarK: yeah, you said it :-) 19:28:46 SumitNaiksatam: ok perfect that is the plan 19:28:49 beyounn: thanks for doing that 19:28:50 :-) 19:29:03 beyounn: but we want this to be sent to the openstack-dev alias 19:29:09 beyounn: sorry for being pushy on this 19:29:10 Sumit: it is still not mail list 19:29:34 Sumit: it is ok, I just really at least get some progress before dump it to the ML 19:29:48 beyounn: we need to describe the issue and send to the -dev mailer 19:29:56 beyounn: so that it comes to the attention of the neutron cores 19:30:08 beyounn: we can have a discussion on the solution in parallel 19:30:27 beyounn: but others have to know that this issues exists, since the cores will be approving the DVR patches 19:30:49 beyonunn is on a meeting now. 19:30:50 ok 19:31:28 beyounn garyduan: thanks 19:31:32 Yes, I have to run to another meeting, talk to you guys later 19:31:47 alright, lets call it a wrap on that happy note then 19:31:54 ok cool 19:31:56 thanks all for joining! 19:32:00 bye! 19:32:01 thanks 19:32:02 bye 19:32:03 bye 19:32:08 #endmeeting