16:01:54 <rkukura> #startmeeting networking_ml2
16:01:55 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:59 <openstack> The meeting name has been set to 'networking_ml2'
16:02:13 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda
16:02:33 <rkukura> #topic Action Items From Last Week
16:03:53 <rkukura> I had the action item to move rcurrans discussion to the email list. He beat me to it!
16:04:18 <rkukura> We'll cover that a bit later
16:04:32 <rcurran> yeah sorry about that but i'd really like to close on this issue
16:05:02 <rkukura> rcurran: Lets try to do that today
16:05:37 <rkukura> mestery had an action to find a volunteer to verify/expand ml2 unit test coverage
16:05:47 <rkukura> Is anyone aware of any progress on that?
16:07:23 <rkukura> 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 <rcurran> i can look into it .... haven't used it yet
16:08:54 <rcurran> but others have here at cisco
16:08:57 <asadoughi> rkukura: tox -e cover neutron.tests.unit.ml2?
16:09:13 <Sukhdev> I have run tox several times - but, wonder how do you identify what is missing>
16:09:14 <rkukura> asadoughi: That's what I recall doing a while back
16:09:30 <asadoughi> Sukhdev: gives you a line coverage report
16:09:43 <asadoughi> rkukura: i'll do it
16:10:07 <rkukura> #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 <rkukura> 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 <rkukura> mestery also had an action to start an etherpad for multi-node ml2 tempest testing
16:11:51 <rcurran> ok, already know that there will be issues w/ the cisco nexus md
16:12:03 <rkukura> Do we know if that has been created?
16:12:17 <matrohon> there a link on the agenda
16:12:43 <rkukura> matrohon: Thanks. I had seen that, but forgot
16:12:50 <matrohon> but multi-node part is not filled
16:13:01 <rkukura> #link https://etherpad.openstack.org/p/multi-node-neutron-tempest
16:14:43 <rkukura> 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 <rkukura> last action from last week was mestery organizing a meeting around multi-node tempest testing and 3rd party testing
16:16:28 <rkukura> I've seen emails on this, and believe a meeting is scheduled.for tomorrow
16:17:05 <matrohon> it was on the mailing list?
16:17:30 <rkukura> 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 <rkukura> The discussion of the meeting was on openstack-dev with the [neutron] tag
16:17:58 <asadoughi> matrohon: http://lists.openstack.org/pipermail/openstack-dev/2013-December/021772.html
16:18:14 <rkukura> asadoughi: Thanks
16:18:15 <matrohon> thanks, i missed it
16:18:42 <rkukura> Anything else on previous action items?
16:20:16 <Sukhdev> i missed it as well. thanks for sharing the info
16:20:37 <Sukhdev> I have a question on the third party testing -
16:20:58 <rkukura> Sukhdev: sure
16:21:29 <Sukhdev> Are we testing every patchset-created? regardless of its impact?
16:21:50 <Sukhdev> or patchset-merged only?
16:22:30 <rkukura> 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 <banix> It can't be patchset-merged; need to vote on the patch.
16:23:01 <matrohon> there has been a discussion about that on the ML
16:23:07 <Sukhdev> Ah OK - thanks for clarification
16:23:33 <rkukura> Sukhdev: I asked the same thing last week
16:23:49 <rkukura> I think there has been email regarding triggering the 3rd party tests
16:24:41 <rkukura> I recall someone saying nova 3rd party tests run on all nova patches, not filtered to changes to the driver
16:24:44 <banix> I would think a 3rd party site can be setup for patches on a particular directory ?
16:24:44 <Sukhdev> 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 <banix> A 3rd party from a given company may be used to only vote on the corresponding plugin
16:25:56 <banix> That is my understanding; may be wrong.
16:26:00 <Sukhdev> <rkukura>: I saw that email - and it concerned me about the traffic it will generate
16:26:35 <rkukura> Seems some sort of filtering will likely be needed.
16:26:55 <rkukura> This seems like a topic for tomorrow's meeting.
16:26:56 <banix> Assuming that the 3rd party site may need to use the 3rd party controller not available to others.
16:27:28 <rkukura> banix: Exactly - that may be a very scarce resource, and multi-node tests are likely to take longer to run.
16:27:49 <rkukura> Lets move on, and cover the testing in tomorrow's meeting, since its not really specific to ML2 drivers
16:29:09 <rkukura> 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 <rkukura> Who wants to kick off the ovs-firewall-driver discussion?
16:30:33 <rkukura> #topic ovs-firewall-driver
16:30:58 <asadoughi> ok
16:30:58 <asadoughi> so i outlined what iwanted to talk about on https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Dec_11.2C_2013
16:31:04 <asadoughi> first i wanted to clarify purpose of the blueprint to make sure we're all on the same page
16:31:16 <rkukura> asadoughi: Good idea
16:31:18 <asadoughi> i'll also update the blueprint page with the following statement
16:31:26 <asadoughi> 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 <asadoughi> Comments? Questions?
16:32:28 <rkukura> asadoughi: Nicely scoped!
16:32:40 <matrohon> did you review the patch from  nachi :
16:32:47 <matrohon> https://review.openstack.org/#/c/21946/
16:33:26 <asadoughi> matrohon: not yet. i was asking for comments and questions on the purpose statement
16:33:48 <matrohon> 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 <rkukura> matrohon: Lets see if we can get consensus about ovs-firewall-driver, then consider that in review nachi's patch
16:34:47 <hemanthravi> asadoughi: will the fw impl be stateful like the iptables impl
16:35:00 <asadoughi> hemanthravi: good segue. that's my next mini-topic
16:35:16 <asadoughi> which is openvswitch statelessness and security groups frontend API and DB
16:35:37 <asadoughi> so openvswitch is stateless in that it doesn't keep track of both sides of one connection
16:35:58 <asadoughi> 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 <asadoughi> so, for openvswitch we'll need one security group rule per flow instead of one rule per connection
16:38:08 <asadoughi> this will require changes to the security groups frontend api and additional values to the db
16:38:29 <asadoughi> the rpc api is already compatible with this possibility, thus does not need to be changed
16:39:08 <asadoughi> 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 <rkukura> asadoughi: I'm OK with adding to the API, but am concerned about behavioural parity for the existing API
16:39:52 <asadoughi> rkukura: ok
16:40:46 <rkukura> 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 <asadoughi> no, it's a good question
16:41:39 <asadoughi> answer is it depends
16:42:01 <rkukura> This is reminding my of configuring linux firewalls before iptables connection tracking
16:42:03 <asadoughi> so, if you allow all egress adding ingress on 22 will work as expected
16:42:24 <asadoughi> rkukura: yeah, it will be similar i suppose
16:43:15 <rkukura> 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 <hemanthravi> some possible security-holes will be to allow egress pkts to any port form 22
16:43:47 <asadoughi> 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 <hemanthravi> and to allow egress pkts after a connection is closed
16:44:56 <ryu25> 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 <asadoughi> ryu25: FWaaS already exists
16:45:48 <matrohon> how does your api evolution will behave with ipablesfirewalldriver?
16:46:18 <rkukura> 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 <asadoughi> matrohon: i don't understand your question. eventually when ovs has connection tracking it will be behaviourally one-to-one
16:46:55 <asadoughi> matrohon: i think statelessness will be a first step, so when statefulness is implemented in ovs neutron users can rejoice
16:47:14 <asadoughi> ..in not having to wait for an implementation
16:47:39 <matrohon> my concern is if you introduce an API evolution, it must compatible with other existing driver
16:48:05 <asadoughi> matrohon: oh, are you talking about the security groups api change as evolution?
16:48:22 <matrohon> asadoughi: yes
16:48:30 <asadoughi> matrohon: so the iptables firewall driver already handles source-port-min source-port-max as expected in the rpc api
16:48:45 <asadoughi> matrohon: so only the frontend api has to change
16:48:54 <asadoughi> matrohon: and db
16:49:07 <matrohon> asadoughi: oh ok, sorry about that
16:50:11 <rkukura> 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 <ryu25> 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 <asadoughi> 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 <rkukura> 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 <rkukura> if the bound MD handles security groups itself without an L2 agent, no RPC-based driver would be used, right?
16:52:38 <ryu25> right, no RPC needed
16:53:13 <ryu25> ok I will have to look into that proposal to get better understanding
16:53:33 <rkukura> 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 <asadoughi> rkukura: i can rehash my agenda on the mailing list to coordinate an additional irc meeting
16:54:16 <rkukura> asadoughi: Sounds good
16:54:57 <rkukura> #action asadoughi to discuss ovs-firewall-driver on email list and schedule IRC meeting on ML2+SG
16:55:37 <rkukura> #topic port unbindi/delete segment info availability
16:55:42 <rkukura> rcurran: Where do we stand on this?
16:56:45 <rcurran> 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 <shivh> please add brocade in the mix. thx
16:57:21 <rkukura> rcurran: Are you leaning towards one of the options discussed in your email?
16:57:30 <matrohon> please add me too
16:57:46 <rcurran> yes, i still believe that the crux of the issue is that our deletes are in the wrong order
16:57:48 <Sukhdev> rcurran: I started the reply to your email, got distracted and never came back to it...sorry
16:58:16 <rkukura> We've only got two minutes left
16:58:33 <rcurran> 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 <HenryG> 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 <rkukura> 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 <rkukura> ZangMingJie: Any update on the TypeDriver refactor?
16:59:41 <rcurran> yeah, sorry wrong terminology
17:00:07 <rkukura> #topic open discussion
17:00:13 <rkukura> Anything else anyone?
17:00:33 <shivh> Zang's discussion on ML?
17:00:50 <doude> What about the summit discussion ML2 RPC Handling ? https://docs.google.com/document/d/1ZHb2zzPmkSOpM6PR8M9sx2SJOJPHblaP5eVXHr5zOFg/edit#heading=h.fybml652slvq
17:01:07 <rkukura> shivh: Yes - I posted a followup last night.
17:01:16 <shivh> will take a look. thx
17:01:23 <rkukura> shivh: Might not be tagged [ml2]
17:01:41 <rkukura> doude: Lets get that on the agenda for next week
17:01:50 <rkukura> Need to wrap up - thanks everyone!
17:01:55 <doude> rkukura: k
17:01:58 <rkukura> #endmeeting