16:02:29 #startmeeting networking_ml2 16:02:29 Meeting started Wed Apr 15 16:02:29 2015 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:33 The meeting name has been set to 'networking_ml2' 16:02:54 #topic Agenda 16:03:05 #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_15.2C_2015 16:03:27 Would anyone like to add anything to the agenda? 16:04:10 #topic Announcements 16:04:34 manishg is out this week 16:04:49 I’ll be out next week, but luckily it’ll be Sukhdev’s turn to chair 16:05:09 And neutron kilo RC-1 is out! 16:05:26 Any other announcements? 16:05:52 Mid-cycle sprint will take place in June 16:06:01 hi rkukura, when will be RC-2 ? 16:06:04 Sukhdev: thanks 16:06:08 And I'm new guy on that meetings: my topic in agenda is portsecurity driver tests 16:06:35 yalie: My undestanding is that additional RCs will be created if and only if critical bugs turn up 16:07:07 dratushnyy: Welcome! Thanks for adding that to the agenda. 16:07:24 #topic Action Items 16:07:25 dratushnyy is a new comer, and he has some ideas on test port-sec :) 16:07:52 rkukura: thanks 16:07:58 dratushnyy: Welcome 16:08:07 dratushnyy: welcome 16:08:15 shivharris isn’t here yet, but had an action: Add next steps for the Drivers decomposition to summit topic etherpad 16:08:21 thanks :) 16:09:26 looks like this is item one, with a followup suggesting a session isn’t needed 16:09:55 Does anyone feel strongly a session on plugin and/or driver decomposition at the summit would be useful? 16:10:43 rkukura: I think we need a topic on the future of the plugin/decomposition 16:10:55 I think the session can cover neutron-lib or others. we can share pain points of decomposition: vendor decomp and advsvc split. 16:11:03 i think what is left to discuss is the fate of ml2 plugin and where it lives 16:11:41 Lets return to this in the agenda section on on summit sessions 16:11:44 banix: right. it is what we raised last week. 16:12:11 shivharris also had an action regarding release notes for kilo 16:12:47 Any update on that? 16:13:55 not here? 16:13:56 Sukhdev and I had an action to discuss with mestery whether working on ML2 sync/TaskFlow at the mid-cycle code sprint would make sense. 16:14:20 yalie: Right, shivharis isn’t here 16:14:44 Sukhdev: I know you were trying to contact mestery regarding this yesterday. Any update? 16:14:46 I have not had a chance to get hold of mestery - will try to have that discussion 16:15:21 And manishg was going to document ML2 sync discussion points, but he isn’t here either. 16:16:03 I’ll record these for next week… 16:16:56 #action Sukhdev to discuss with mestery about task flow during mid-cycle sprint 16:17:18 #action manishg to document the discussion point related to ML2 Sync 16:17:29 rkukura: sounds good 16:17:41 I’m leaving out the decomposition action since we’ll discuss that shortly 16:18:04 And I think release notes and documentation were dicussed in depth at this weeks neutron IRC meeting. 16:18:15 Anything else on last week’s action items? 16:18:45 #topic Finalize recommendations to mestery on ML2 summit sessions 16:19:04 OK, I see three categories here: 16:19:19 1) sync/TaskFlow/error handling 16:19:41 2) decomposition, location of ML2 tree, … 16:20:22 3) next steps in evolution of the driver API, for which I added a couple ideas to the eitherpad yesterday 16:20:33 #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics 16:21:41 I’m sure a number of other topics effect ML2, but I’d like to focus here on the ones driven by driver maintainers and others that want to improve ML2 16:21:56 All of these are good 16:22:39 Given that there is a limited amount of time and space at the summit, I don’t think its reasonable to ask for too many ML2-specific sessions 16:23:07 will we choose some ones which get most attension +1? 16:23:10 I am not able to open the etherpad - does others have the issue? 16:23:21 But we should figure out what we really need to discuss in-person, and see if we can organize that into a couple of sessions, and hopefully mestery will include those. 16:23:33 Sukhdev: chrome? 16:23:40 yalie: yes 16:23:46 Sukhdev: try again - worked second try for me this morning 16:23:48 Sukhdev: ctrl +f5 16:24:17 Sukhdev: have you tried reload? etherpad has been upgraded. 16:24:48 yes, that worked - thanks amotoki 16:25:36 I’m thinking we should try to a full working group session on sync/error handling/TaskFlow, assuming we can do enough hopework before then to have some clear options to evaluate and decide between. 16:26:11 Does that seem reasonable? 16:26:47 :) 16:26:51 rkukura: +1 16:27:09 sounds good. If not, friday working table 16:27:50 So what do we really need to cover that’s ML2-specific on decomposition next steps and related items? 16:28:09 amotoki: Lets try for a session, and use Friday to finish up if needed 16:28:56 Looks like this is related to item 3 16:30:29 Do we think ML2 and the L2 agents should be moved to a separate neutron repo, ala *aaS? 16:31:26 what "pros" for it? 16:31:54 dratushnyy: good question 16:33:07 can't find any for now 16:33:15 it could be argued that moving the data plane implementations out would allow testing of the API and REST stuff in the core repo to be cleaned up and impoved 16:33:24 rkukura: you mean ML2 and L2 into two separate repos or into one? 16:33:50 Sukhdev: I’d think the reference L2 agents would belong in the same repo as ML2, whatever that is 16:34:44 A separate set of core reviewers focused on ML2 and the reference dataplane(s) might help scale up the neutron team’s productivity 16:34:48 rkukura: so cleaning is ok, but more repos - more work to config and manage 16:34:56 there are others who might be using l2 agents other than ML2 16:35:09 rkukura: would you have the l3 agent, metadata and dhcp agents in a separate repo from ml2 and ovs/lb agents? 16:35:10 dratushnyy :-) 16:35:40 So this is L2 repo, Fwaas is for L3 ? 16:35:46 amuller: I think that would need to be discussed. I’m not pushing this proposal, but am certainly willing to discuss it if there is interest 16:36:45 yalie: The various *aaS extension now each have their own repo. I think this would follow that model, but exactly where to draw the lines would remain to be discussed 16:37:00 rkukura: think same. and maybe any 'use cases' for that model ? 16:37:28 mean for ML2 separate repo 16:38:39 So far, I’m not hearing strong advocacy from this team for moving ML2 (and maybe other stuff) into a separate repo, but not strong opposition either. Seems this is really a neutron-level topic rather than ML2-specific then. 16:39:20 rkukura: agree 16:39:27 So other than repo-reorganization, what next steps on decomposition need to be discussed at the summit? 16:40:13 rkukura: I can't think of any 16:41:03 Drivers seem to have followed two different approaches: 1) in-tree entry point inherits driver class from backend-library, and 2) in-tree driver code implements/uses ML2 driver APIs, 16:41:29 Is there a need to try to converge on a single approach, or continue leaving this up to each driver? 16:42:05 rkukura: I'd love to hear concrete pros for moving parts of the reference implementation, I can only think of negatives 16:42:07 but I'm biased 16:42:08 rkukura: I think we should leave that to the driver owners 16:42:13 rkukura: I don't see a strong reason to remove it and place it in a diff repo 16:42:22 rkukura: it would make my life a lot harder on a personal level 16:42:53 sadasu: by it I mean ML2 16:42:56 and on some testing level too 16:43:12 Sounds to me like the ML2 team won’t be pushing for summit sessions on these topics, but will participate if others drive them and they get scheduled 16:43:15 amuller: share negatives - it will be interesting to hear your views 16:43:39 rkukura: makes sense; agree 16:44:13 So the 3rd category was some of the unfinished items that we’ve been kicking from release to release, like moving code to extension drivers, enforcing extension semanics, improving securiy group flexibility, etc. 16:44:41 Can we pack that sort thing into a session and try to prioritize for liberty? 16:44:42 rkukura: esp for the decomposition, it was an effort driven by the cores, and I am still having a somewhat hard time explaining the rationale to folks who don't participate in Neutron on a daily basis 16:44:50 Sukhdev: It depends on how it's divided right, but I imagine working on L3 HA and DVR with everything split up, if ML2 and the L3 agent are in separate repos, or if L3 and OVS agent are in separate repos, it makes it a lot harder 16:45:37 amuller: Good points. If we really had a layered architecture it would be more workable to use separate repos. 16:46:03 I want to wrap up the summit session discussion so we can cover the rest of the agenda 16:46:23 Do we think two session specific to ML2 are sufficient? 16:46:24 So, it seems leaving it as-is reasonable 16:46:41 One on sync/error/TaskFlow, the other on driver API next steps? 16:47:37 rkukura: I see a topic on decomposition on the etherpad already 16:48:31 rkukura: perhaps ML2 can be covered under that 16:49:04 Sukhdev: +1, but I’m not sure if we are pushing for that topic, or if someone else i 16:49:10 is 16:49:23 Ok, lets move on… 16:49:39 #topic Quick update on DVR UT/fix/cleanup work 16:51:17 We discussed this in depth last week. I made good progress on the approach we discussed, but am now thinking we might want to take a different approach, where the current and previous port dictionaries always reflect the attributres that will be returned to the client, and we add PortContext attributes for all the state that might be host-specific in distributed ports. 16:52:12 This would follow the approach in the original DVR code, where they added PortContext.host. We’d also add PortContext.vif_type, PortContext.previous_vif_type, ... 16:52:40 I’ll send an email to openstack-dev once this has gelled a bit, and we can decide which approach makes more sense. 16:52:56 #topic portsecurity tests: unit, functional and scenario 16:53:29 dratushnyy: Is this your topic? 16:53:37 yep 16:54:11 go ahead... 16:54:11 so this one is quite short. unit tests is implemented, so I have few ideas to api tests and scenario tests 16:54:24 should I put them here? 16:54:32 sure 16:54:34 ok 16:54:40 1 Create port without specifying ‘port_security_enabled’ and verify that attribute is enabled by default 16:54:46 Create port with specifying ‘port_security_enabled’ = True 16:54:53 Create port with specifying ‘port_security_enabled’ = False 16:55:04 Try to create port with invalid parameters for ‘port_security_enabled’ 16:55:18 Try to create port with both parameters (security-group, no-security-group) provided and ‘port_security_enabled'=True\False 16:55:42 Update port with no security group attached, set attribute to False 16:55:46 dratushnyy: Would these be tempest scenario tests that actually validate the datapath? 16:56:30 this is just for api. for scenario "Verify VM connectivity (try to send\receive packets) through insecure port" 16:56:53 I think yes 16:56:55 Verify that tenant is able to attach ports with ‘port_security_enabled’=True or ‘port_security_enabled’=False to VM 16:57:01 and update from yalie 16:57:07 [yalei] I think it’s a good idea to test updating the port associated to a VM, and also test attaching the updated port to a VM. 16:57:30 also tests for CLI 16:57:47 so, what your thoughts 16:57:54 ? 16:58:42 yes, we find there would be some confusing when specify a port using 'nova boot', then dratushnyy want to add a complete test. 16:59:10 I’m in favor of tempest tests verifying all this works as expected. 16:59:27 the test in review is just to connetivity, and simple. 16:59:31 yalie: Where can we find those tests? 17:00:02 https://review.openstack.org/#/c/167910/ is for API cases 17:00:03 We need to wrap up 17:00:14 dratushnyy will extend it 17:00:16 Any last comments? 17:00:28 Lets folluwup on this in gerrit. 17:00:35 thanks 17:00:39 Thanks everyone! 17:00:41 ok:) 17:00:44 thanks :) 17:00:45 thanks all 17:00:48 bye 17:00:49 #endmeeting