16:01:11 #startmeeting networking_ml2 16:01:12 Meeting started Wed Mar 2 16:01:11 2016 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:16 The meeting name has been set to 'networking_ml2' 16:01:28 #topic: Agenda 16:01:36 #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_March_2.2C_2016 16:01:58 It is a very brief agenda today - so, probably be a short meeting 16:02:04 +1 16:02:20 #topic: Announcements 16:02:30 M3 is later this week 16:03:01 Anybody has anything else to announce? 16:03:45 #topic: Modular L2 agent update 16:04:36 most of the code is already in - I reviewed the doc patch 16:04:45 https://review.openstack.org/#/c/282349 16:05:11 Andreas does not seem to be here foter any other upda 16:05:48 opps hit the wrong key - meant to say he is not here for any other update 16:06:29 have a look at his patch and provide any feedback 16:06:55 #topic: Routed networks 16:07:24 Looks like this was discussed during the mid-cycle - which I missed 16:07:40 it has moved into implementation phase 16:07:52 I do not have any further update - 16:08:01 spec hasn’t merged, so I think feedback is still possible 16:08:16 I was watching it to make sure that there is not much impact on ML2 16:08:24 carl_baldwin uploaded a new patch on 3/1, I’m reviewing that one now 16:08:45 rkukura : yes - in fact, there is lot of feedback coming - 16:08:53 I’m still kind of uncomfortable changing the semantics of a neutron network to no longer be an L2 broadcast domain 16:08:59 so, feel free to provide your feedback 16:09:36 I can live with it being optionally an L2 broadcast domain, as long as that is clearly visible from the API 16:10:35 rkukura : you should review the patch and post the comments 16:10:44 Sukhdev: I am and will 16:11:06 Curious if others here have thought about the implications of this 16:11:45 there have been a lot of debate about it 16:12:17 in the previous mid-cycle, when it was introduced, there was quite a bit of dicussion 16:13:32 Anything else on this? 16:14:25 #topic: Open Discussion 16:14:48 I did not have anything else on the agenda 16:15:10 Any body wants to discuss anything today? 16:15:45 * Sukhdev waiting 16:16:02 Has anyone else seen any need for ML2 to support extension drivers and maybe mech driver calls on subnet pools and address scopes? 16:17:34 I guess silence means either no or no opinion :-) 16:17:38 guess so 16:18:10 or we do not have critical mass to answer your question :-) 16:18:48 my team is working on a driver that may need to track the association between address scopes and subnets, so we may be looking at adding support for this to ML2 16:19:31 what do you mean by address scope? 16:20:00 its a neutron core resource, added in liberty, I think 16:20:35 rkukura: why do you need to track them? 16:20:52 by knowing that subnets are associated with the the same address scope, you know they don’t overlap and are potentially routable 16:21:00 does it have to do with carving out of the IP address space across sub-nets? 16:21:11 yes 16:21:29 subnets can belong to subnet pools which can belong to address scopes 16:22:15 anyone, just wanted to see if anyone else had thought about ML2 support for these 16:23:25 s/anyone/anyway/ 16:23:33 that’s it from me 16:23:54 rkukura : so, at the time of create of sub-net, you do not specify the cidr, instead specify the address scope? 16:24:27 actually, the subnet pool 16:24:45 and the pool can be associated with an address scope 16:25:20 hmm...so these new APIs are already merged and available? 16:25:48 yes 16:25:52 so, create address scope, then sub-net pools, and then subnet 16:25:57 right 16:26:10 but the address scope attribute of subnet pool is mutable 16:26:30 I see 16:26:54 rkukura: i guess a callback for SUBNETPOOL_ADDRESS_SCOPE is enough for many cases 16:27:30 right, although my preference would be to treat subnet pools and address scopes just like the other resources in ML2 16:29:18 rkukura: i tend to agree but many folks seem to like callbacks recently. 16:29:37 the callbacks are not really usable without significant work 16:29:56 there are no callbacks for most resources, and no way to really see what is changed on updates 16:30:20 right now, they are just special cased when needed, rather than uniformily implemented 16:31:09 I guess the idea is to get the state of resource by query the DB 16:32:23 however, the question is who updates the DB, if multiple entities are trigged on callbak 16:33:07 lets wrap this up for today 16:33:22 +1 16:33:47 sure 16:33:56 so, if nothing else on this, I good to call it a day 16:34:06 unless there are other topics anyone wants to discuss 16:34:15 nothing from me. 16:34:26 OK - cool - we are done then 16:34:29 Thanks 16:34:31 thank you! 16:34:33 thanks Sukhdev! 16:34:35 bye 16:34:39 #endmeeting