16:01:54 #startmeeting networking_ml2 16:01:55 Meeting started Wed Dec 11 16:01:54 2013 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:59 The meeting name has been set to 'networking_ml2' 16:02:13 #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 16:02:33 #topic Action Items From Last Week 16:03:53 I had the action item to move rcurrans discussion to the email list. He beat me to it! 16:04:18 We'll cover that a bit later 16:04:32 yeah sorry about that but i'd really like to close on this issue 16:05:02 rcurran: Lets try to do that today 16:05:37 mestery had an action to find a volunteer to verify/expand ml2 unit test coverage 16:05:47 Is anyone aware of any progress on that? 16:07:23 Would anyone like to volunteer to run the tox coverage tool on master and report a summary of where work is needed in ml2 coverage via email and/or next week's meeting? 16:08:44 i can look into it .... haven't used it yet 16:08:54 but others have here at cisco 16:08:57 rkukura: tox -e cover neutron.tests.unit.ml2? 16:09:13 I have run tox several times - but, wonder how do you identify what is missing> 16:09:14 asadoughi: That's what I recall doing a while back 16:09:30 Sukhdev: gives you a line coverage report 16:09:43 rkukura: i'll do it 16:10:07 #action asadoughi to run the tox coverage tool on master and report a summary of where work is needed in ml2 coverage via email and/or next week's meeting 16:11:03 rcurran: Feel free to collaborate with asadoughi on that action, but hopefully there will be unblocked on the port unbind/delete stuff 16:11:48 mestery also had an action to start an etherpad for multi-node ml2 tempest testing 16:11:51 ok, already know that there will be issues w/ the cisco nexus md 16:12:03 Do we know if that has been created? 16:12:17 there a link on the agenda 16:12:43 matrohon: Thanks. I had seen that, but forgot 16:12:50 but multi-node part is not filled 16:13:01 #link https://etherpad.openstack.org/p/multi-node-neutron-tempest 16:14:43 I started looking into how my employer's internal multi-node OpenStack CI testing is done, and will add whatever I find to the etherpad. Its based mainly on packages installed by packstack rather than devstack, but is integrated with jenkins. 16:15:33 last action from last week was mestery organizing a meeting around multi-node tempest testing and 3rd party testing 16:16:28 I've seen emails on this, and believe a meeting is scheduled.for tomorrow 16:17:05 it was on the mailing list? 16:17:30 It sounds like the agenda covers multi-node testing internal to OpenStack jenkins as well as 3rd party, so I'd encourage all to attend. 16:17:54 The discussion of the meeting was on openstack-dev with the [neutron] tag 16:17:58 matrohon: http://lists.openstack.org/pipermail/openstack-dev/2013-December/021772.html 16:18:14 asadoughi: Thanks 16:18:15 thanks, i missed it 16:18:42 Anything else on previous action items? 16:20:16 i missed it as well. thanks for sharing the info 16:20:37 I have a question on the third party testing - 16:20:58 Sukhdev: sure 16:21:29 Are we testing every patchset-created? regardless of its impact? 16:21:50 or patchset-merged only? 16:22:30 Sukhdev: I think the intent was for the reports to trigger on proposed patches so the results could be considered in the review 16:22:36 It can't be patchset-merged; need to vote on the patch. 16:23:01 there has been a discussion about that on the ML 16:23:07 Ah OK - thanks for clarification 16:23:33 Sukhdev: I asked the same thing last week 16:23:49 I think there has been email regarding triggering the 3rd party tests 16:24:41 I recall someone saying nova 3rd party tests run on all nova patches, not filtered to changes to the driver 16:24:44 I would think a 3rd party site can be setup for patches on a particular directory ? 16:24:44 I saw one email, it did not really clarify which triggers to use - I was concerned about the amount of traffic and wanted to design the back-end accordingly 16:25:48 A 3rd party from a given company may be used to only vote on the corresponding plugin 16:25:56 That is my understanding; may be wrong. 16:26:00 : I saw that email - and it concerned me about the traffic it will generate 16:26:35 Seems some sort of filtering will likely be needed. 16:26:55 This seems like a topic for tomorrow's meeting. 16:26:56 Assuming that the 3rd party site may need to use the 3rd party controller not available to others. 16:27:28 banix: Exactly - that may be a very scarce resource, and multi-node tests are likely to take longer to run. 16:27:49 Lets move on, and cover the testing in tomorrow's meeting, since its not really specific to ML2 drivers 16:29:09 The agenda lists the ovs-firewall-driver development discussion, but I'd also like to cover ZangMingJie's TypeDriver patch and rcurran's MechanismDriver discussion 16:30:10 Who wants to kick off the ovs-firewall-driver discussion? 16:30:33 #topic ovs-firewall-driver 16:30:58 ok 16:30:58 so i outlined what iwanted to talk about on https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Dec_11.2C_2013 16:31:04 first i wanted to clarify purpose of the blueprint to make sure we're all on the same page 16:31:16 asadoughi: Good idea 16:31:18 i'll also update the blueprint page with the following statement 16:31:26 To support the security groups extension in the OVS neutron agent through OVS flows using the existing OVS library with feature parity to the existing iptables-based implementations. In Icehouse, the existing openvswitch plugin is being deprecated, so the blueprint is compatible with the ML2 plugin with the openvswitch mechanism driver. 16:31:35 Comments? Questions? 16:32:28 asadoughi: Nicely scoped! 16:32:40 did you review the patch from nachi : 16:32:47 https://review.openstack.org/#/c/21946/ 16:33:26 matrohon: not yet. i was asking for comments and questions on the purpose statement 16:33:48 because it's quite the same topic, and maybe a good idea woulld be to let the firewall driver to implement the security group extension 16:34:30 matrohon: Lets see if we can get consensus about ovs-firewall-driver, then consider that in review nachi's patch 16:34:47 asadoughi: will the fw impl be stateful like the iptables impl 16:35:00 hemanthravi: good segue. that's my next mini-topic 16:35:16 which is openvswitch statelessness and security groups frontend API and DB 16:35:37 so openvswitch is stateless in that it doesn't keep track of both sides of one connection 16:35:58 so listed in this etherpad https://etherpad.openstack.org/p/ovs-firewall-driver-stateless-2 are four flows of two types of connections 16:37:50 so, for openvswitch we'll need one security group rule per flow instead of one rule per connection 16:38:08 this will require changes to the security groups frontend api and additional values to the db 16:38:29 the rpc api is already compatible with this possibility, thus does not need to be changed 16:39:08 i was referred to openvswitch/nicira-ext.h NXAST_LEARN for a possible, magical stateful unicorn but i haven't grokked it yet 16:39:08 asadoughi: I'm OK with adding to the API, but am concerned about behavioural parity for the existing API 16:39:52 rkukura: ok 16:40:46 Maybe this is a silly question, but would the typical existing SG rule allowing TCP port 22 from everywhere still be sufficient, or would additional rules be needed with this driver? 16:41:24 no, it's a good question 16:41:39 answer is it depends 16:42:01 This is reminding my of configuring linux firewalls before iptables connection tracking 16:42:03 so, if you allow all egress adding ingress on 22 will work as expected 16:42:24 rkukura: yeah, it will be similar i suppose 16:43:15 I seem to recall setting up firewalls to reject only SYN packets from TCP ports that were not open, but allowing packets in both directions for existing connections 16:43:46 some possible security-holes will be to allow egress pkts to any port form 22 16:43:47 one that will not be the same: if you allow all egress, for example instance ssh client to remote ssh server, you'll have to still add the reverse flow of remote ssh server serving to instance ssh client 16:44:09 and to allow egress pkts after a connection is closed 16:44:56 I don't want to interrupt the work that has already started, and maybe this is a crazy idea, but how do you all feel about implementing security group as a service type framework (just like L3 router service)? 16:45:10 ryu25: FWaaS already exists 16:45:48 how does your api evolution will behave with ipablesfirewalldriver? 16:46:18 ryu25: I was hoping this new ovs-firewall-driver would be purely a new driver in the L2 agent, not a new API/DB/RPC in the server 16:46:20 matrohon: i don't understand your question. eventually when ovs has connection tracking it will be behaviourally one-to-one 16:46:55 matrohon: i think statelessness will be a first step, so when statefulness is implemented in ovs neutron users can rejoice 16:47:14 ..in not having to wait for an implementation 16:47:39 my concern is if you introduce an API evolution, it must compatible with other existing driver 16:48:05 matrohon: oh, are you talking about the security groups api change as evolution? 16:48:22 asadoughi: yes 16:48:30 matrohon: so the iptables firewall driver already handles source-port-min source-port-max as expected in the rpc api 16:48:45 matrohon: so only the frontend api has to change 16:48:54 matrohon: and db 16:49:07 asadoughi: oh ok, sorry about that 16:50:11 Some good discussion here, but we should reserve a couple minutes for each of the other topics as well. Are there any other meetings scheduled regarding ovs-firewall-driver? 16:50:17 rkukura: understood. I guess what I'm wondering is, if a vendor wants to migrate to ML2 and wants to implement the SG features without relying on the agents running on the compute hosts, how could it achieve it? 16:51:00 nothing with high priority to discuss. see more on the agenda page. we could start another meeting or more mailing list discussions if that's worthy? 16:51:18 ryu25: I would hope that's where nachi's VIF patch ties in - so the bound mechanism driver can influence what happens on the compute node 16:52:11 if the bound MD handles security groups itself without an L2 agent, no RPC-based driver would be used, right? 16:52:38 right, no RPC needed 16:53:13 ok I will have to look into that proposal to get better understanding 16:53:33 Seems we need to continue discussion of SGs with ML2 - do we need a separate meeting, or just use the mailing list? 16:54:02 rkukura: i can rehash my agenda on the mailing list to coordinate an additional irc meeting 16:54:16 asadoughi: Sounds good 16:54:57 #action asadoughi to discuss ovs-firewall-driver on email list and schedule IRC meeting on ML2+SG 16:55:37 #topic port unbindi/delete segment info availability 16:55:42 rcurran: Where do we stand on this? 16:56:45 if you don't mind i think that i can come up w/ a code change for the crux of the issue and put out for a private review (bobk, kylem, l2pop, arista engs) and resolve this quicker that way 16:57:07 please add brocade in the mix. thx 16:57:21 rcurran: Are you leaning towards one of the options discussed in your email? 16:57:30 please add me too 16:57:46 yes, i still believe that the crux of the issue is that our deletes are in the wrong order 16:57:48 rcurran: I started the reply to your email, got distracted and never came back to it...sorry 16:58:16 We've only got two minutes left 16:58:33 create_port_postcommit() is the last call in create_port() therefore it has the most (or could) dependencies; therefore it should be one of the first methods called on delete 16:59:17 rcurran, looks like it might be better to push the review and mark it WIP, rather than cherry-pick who gets to see it 16:59:20 Lets follwup on rcurran's email thread ASAP, and any kind of WIP patch to review would be great. I don't see a need to necessarily make it private - WIP might be sufficient 16:59:41 ZangMingJie: Any update on the TypeDriver refactor? 16:59:41 yeah, sorry wrong terminology 17:00:07 #topic open discussion 17:00:13 Anything else anyone? 17:00:33 Zang's discussion on ML? 17:00:50 What about the summit discussion ML2 RPC Handling ? https://docs.google.com/document/d/1ZHb2zzPmkSOpM6PR8M9sx2SJOJPHblaP5eVXHr5zOFg/edit#heading=h.fybml652slvq 17:01:07 shivh: Yes - I posted a followup last night. 17:01:16 will take a look. thx 17:01:23 shivh: Might not be tagged [ml2] 17:01:41 doude: Lets get that on the agenda for next week 17:01:50 Need to wrap up - thanks everyone! 17:01:55 rkukura: k 17:01:58 #endmeeting