16:02:29 <rkukura> #startmeeting networking_ml2
16:02:29 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:33 <openstack> The meeting name has been set to 'networking_ml2'
16:02:54 <rkukura> #topic Agenda
16:03:05 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_15.2C_2015
16:03:27 <rkukura> Would anyone like to add anything to the agenda?
16:04:10 <rkukura> #topic Announcements
16:04:34 <rkukura> manishg is out this week
16:04:49 <rkukura> I’ll be out next week, but luckily it’ll be Sukhdev’s turn to chair
16:05:09 <rkukura> And neutron kilo RC-1 is out!
16:05:26 <rkukura> Any other announcements?
16:05:52 <Sukhdev> Mid-cycle sprint will take place in June
16:06:01 <yalie> hi rkukura, when will be RC-2 ?
16:06:04 <rkukura> Sukhdev: thanks
16:06:08 <dratushnyy> And I'm new guy on that meetings: my topic in agenda is portsecurity driver tests
16:06:35 <rkukura> yalie: My undestanding is that additional RCs will be created if and only if critical bugs turn up
16:07:07 <rkukura> dratushnyy: Welcome! Thanks for adding that to the agenda.
16:07:24 <rkukura> #topic Action Items
16:07:25 <yalie> dratushnyy is a new comer, and he has some ideas on test port-sec :)
16:07:52 <yalie> rkukura: thanks
16:07:58 <Sukhdev> dratushnyy: Welcome
16:08:07 <amotoki> dratushnyy: welcome
16:08:15 <rkukura> shivharris isn’t here yet, but had an action: Add next steps for the Drivers decomposition to summit topic etherpad
16:08:21 <dratushnyy> thanks :)
16:09:26 <rkukura> looks like this is item one, with a followup suggesting a session isn’t needed
16:09:55 <rkukura> Does anyone feel strongly a session on plugin and/or driver decomposition at the summit would be useful?
16:10:43 <Sukhdev> rkukura: I think we need a topic on the future of the plugin/decomposition
16:10:55 <amotoki> 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 <banix> i think what is left to discuss is the fate of ml2 plugin and where it lives
16:11:41 <rkukura> Lets return to this in the agenda section on on summit sessions
16:11:44 <amotoki> banix: right. it is what we raised last week.
16:12:11 <rkukura> shivharris also had an action regarding release notes for kilo
16:12:47 <rkukura> Any update on that?
16:13:55 <yalie> not here?
16:13:56 <rkukura> 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 <rkukura> yalie: Right, shivharis isn’t here
16:14:44 <rkukura> Sukhdev: I know you were trying to contact mestery regarding this yesterday. Any update?
16:14:46 <Sukhdev> I have not had a chance to get hold of mestery - will try to have that discussion
16:15:21 <rkukura> And manishg was going to document ML2 sync discussion points, but he isn’t here either.
16:16:03 <rkukura> I’ll record these for next week…
16:16:56 <rkukura> #action Sukhdev to discuss with mestery about task flow during mid-cycle sprint
16:17:18 <rkukura> #action manishg to document the discussion point related to ML2 Sync
16:17:29 <Sukhdev> rkukura: sounds good
16:17:41 <rkukura> I’m leaving out the decomposition action since we’ll discuss that shortly
16:18:04 <rkukura> And I think release notes and documentation were dicussed in depth at this weeks neutron IRC meeting.
16:18:15 <rkukura> Anything else on last week’s action items?
16:18:45 <rkukura> #topic Finalize recommendations to mestery on ML2 summit sessions
16:19:04 <rkukura> OK, I see three categories here:
16:19:19 <rkukura> 1) sync/TaskFlow/error handling
16:19:41 <rkukura> 2) decomposition, location of ML2 tree, …
16:20:22 <rkukura> 3) next steps in evolution of the driver API, for which I added a couple ideas to the eitherpad yesterday
16:20:33 <rkukura> #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics
16:21:41 <rkukura> 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 <Sukhdev> All of these are good
16:22:39 <rkukura> 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 <yalie> will we choose some ones which get most attension +1?
16:23:10 <Sukhdev> I am not able to open the etherpad - does others have the issue?
16:23:21 <rkukura> 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 <yalie> Sukhdev:  chrome?
16:23:40 <Sukhdev> yalie: yes
16:23:46 <rkukura> Sukhdev: try again - worked second try for me this morning
16:23:48 <yalie> Sukhdev: ctrl +f5
16:24:17 <amotoki> Sukhdev: have you tried reload? etherpad has been upgraded.
16:24:48 <Sukhdev> yes, that worked - thanks amotoki
16:25:36 <rkukura> 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 <rkukura> Does that seem reasonable?
16:26:47 <GLaupre> :)
16:26:51 <Sukhdev> rkukura: +1
16:27:09 <amotoki> sounds good. If not, friday working table
16:27:50 <rkukura> So what do we really need to cover that’s ML2-specific on decomposition next steps and related items?
16:28:09 <rkukura> amotoki: Lets try for a session, and use Friday to finish up if needed
16:28:56 <rkukura> Looks like this is related to item 3
16:30:29 <rkukura> Do we think ML2 and the L2 agents should be moved to a separate neutron repo, ala *aaS?
16:31:26 <dratushnyy> what "pros" for it?
16:31:54 <rkukura> dratushnyy: good question
16:33:07 <dratushnyy> can't find any for now
16:33:15 <rkukura> 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 <Sukhdev> rkukura: you mean ML2 and L2 into two separate repos or into one?
16:33:50 <rkukura> Sukhdev: I’d think the reference L2 agents would belong in the same repo as ML2, whatever that is
16:34:44 <rkukura> 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 <dratushnyy> rkukura: so  cleaning is ok, but more repos - more work to config and manage
16:34:56 <Sukhdev> there are others who might be using l2 agents other than ML2
16:35:09 <amuller> rkukura: would you have the l3 agent, metadata and dhcp agents in a separate repo from ml2 and ovs/lb agents?
16:35:10 <Sukhdev> dratushnyy :-)
16:35:40 <yalie> So this is L2 repo, Fwaas is for L3 ?
16:35:46 <rkukura> 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 <rkukura> 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 <dratushnyy> rkukura: think same. and maybe any 'use cases' for that model ?
16:37:28 <dratushnyy> mean for ML2 separate repo
16:38:39 <rkukura> 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 <yalie> rkukura: agree
16:39:27 <rkukura> So other than repo-reorganization, what next steps on decomposition need to be discussed at the summit?
16:40:13 <Sukhdev> rkukura: I can't think of any
16:41:03 <rkukura> 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 <rkukura> Is there a need to try to converge on a single approach, or continue leaving this up to each driver?
16:42:05 <amuller> rkukura: I'd love to hear concrete pros for moving parts of the reference implementation, I can only think of negatives
16:42:07 <amuller> but I'm biased
16:42:08 <Sukhdev> rkukura: I think we should leave that to the driver owners
16:42:13 <sadasu> rkukura: I don't see a strong reason to remove it and place it in a diff repo
16:42:22 <amuller> rkukura: it would make my life a lot harder on a personal level
16:42:53 <sadasu> sadasu: by it I mean ML2
16:42:56 <dratushnyy> and on some testing level too
16:43:12 <rkukura> 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 <Sukhdev> amuller: share negatives - it will be interesting to hear your views
16:43:39 <banix> rkukura: makes sense; agree
16:44:13 <rkukura> 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 <rkukura> Can we pack that sort thing into a session and try to prioritize for liberty?
16:44:42 <sadasu> 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 <amuller> 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 <rkukura> amuller: Good points. If we really had a layered architecture it would be more workable to use separate repos.
16:46:03 <rkukura> I want to wrap up the summit session discussion so we can cover the rest of the agenda
16:46:23 <rkukura> Do we think two session specific to ML2 are sufficient?
16:46:24 <Sukhdev> So, it seems leaving it as-is reasonable
16:46:41 <rkukura> One on sync/error/TaskFlow, the other on driver API next steps?
16:47:37 <Sukhdev> rkukura: I see a topic on decomposition on the etherpad already
16:48:31 <Sukhdev> rkukura: perhaps ML2 can be covered under that
16:49:04 <rkukura> Sukhdev: +1, but I’m not sure if we are pushing for that topic, or if someone else i
16:49:10 <rkukura> is
16:49:23 <rkukura> Ok, lets move on…
16:49:39 <rkukura> #topic Quick update on DVR UT/fix/cleanup work
16:51:17 <rkukura> 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 <rkukura> 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 <rkukura> 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 <rkukura> #topic portsecurity tests: unit, functional and scenario
16:53:29 <rkukura> dratushnyy: Is this your topic?
16:53:37 <dratushnyy> yep
16:54:11 <rkukura> go ahead...
16:54:11 <dratushnyy> so this one is quite short. unit tests is implemented, so I have few ideas to api tests and scenario tests
16:54:24 <dratushnyy> should I put them here?
16:54:32 <rkukura> sure
16:54:34 <dratushnyy> ok
16:54:40 <dratushnyy> 1 Create port without specifying ‘port_security_enabled’ and verify that attribute is enabled by default
16:54:46 <dratushnyy> Create port with specifying ‘port_security_enabled’ = True
16:54:53 <dratushnyy> Create port with specifying ‘port_security_enabled’ = False
16:55:04 <dratushnyy> Try to create port with invalid parameters for ‘port_security_enabled’
16:55:18 <dratushnyy> Try to create port with both parameters (security-group, no-security-group) provided and ‘port_security_enabled'=True\False
16:55:42 <dratushnyy> Update port with no security group attached, set attribute to False
16:55:46 <rkukura> dratushnyy: Would these be tempest scenario tests that actually validate the datapath?
16:56:30 <dratushnyy> this is just for api. for scenario "Verify VM connectivity (try to send\receive packets) through insecure port"
16:56:53 <yalie> I think yes
16:56:55 <dratushnyy> Verify that tenant is able to attach ports with ‘port_security_enabled’=True or ‘port_security_enabled’=False to VM
16:57:01 <dratushnyy> and update from yalie
16:57:07 <dratushnyy> [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 <dratushnyy> also tests for CLI
16:57:47 <dratushnyy> so, what your thoughts
16:57:54 <dratushnyy> ?
16:58:42 <yalie> 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 <rkukura> I’m in favor of tempest tests verifying all this works as expected.
16:59:27 <yalie> the test in review is just to connetivity, and simple.
16:59:31 <GLaupre> yalie: Where can we find those tests?
17:00:02 <yalie> https://review.openstack.org/#/c/167910/ is for API cases
17:00:03 <rkukura> We need to wrap up
17:00:14 <yalie> dratushnyy will extend it
17:00:16 <rkukura> Any last comments?
17:00:28 <rkukura> Lets folluwup on this in gerrit.
17:00:35 <yalie> thanks
17:00:39 <rkukura> Thanks everyone!
17:00:41 <dratushnyy> ok:)
17:00:44 <dratushnyy> thanks :)
17:00:45 <yalie> thanks all
17:00:48 <banix> bye
17:00:49 <rkukura> #endmeeting