15:01:15 #startmeeting neutron_routed_networks 15:01:16 Meeting started Tue Apr 12 15:01:15 2016 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:20 The meeting name has been set to 'neutron_routed_networks' 15:01:30 #topic Announcements 15:01:37 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Routed-Networks 15:01:47 o/ 15:01:52 I don't have any announcements 15:01:56 Anyone else? 15:02:07 nope 15:02:11 Well I guess I can use this chance to introduce myself 15:02:21 o/ 15:02:31 o/ 15:02:49 carl_baldwin: just remind the team the summit is 2 weeks aways 15:03:12 mlavalle: Yes! It is coming fast. 15:03:18 not coming .... Visa not yet approved :( 15:03:30 stuck in Administrative processing.... 15:03:44 will wait for the notes :) 15:03:49 reedip__: Hope you get it soon 15:03:52 reedip__: Very sorry to hear that. 15:04:35 Okay, moving on. 15:04:45 #topic Progress 15:05:10 Progress slowed down this week a bit for me. But, there is still some. 15:05:21 #topic Basic CRUD 15:05:47 This patch has stalled. I got feedback from armax that I need to address which will result in some rework. 15:06:04 I decided to finish up my action items from last week before I go back to address that. 15:06:06 carl_baldwin: is the rework just making it its own plugin and not a mixin to ml2? 15:06:40 blogan: I think you're thinking down the right lines but the terminology might be a little off. 15:06:54 The feedback is to use the extension manager instead of a mixin. 15:07:07 The mixin was never really tied to ml2. 15:07:44 Anyway, I'm hoping to sneak in the changes before summit. But, with summit approaching, it is beginning to take my time away. 15:08:01 carl_baldwin: i guess i dont understand how the extension manager comes into play, but I can wait to see 15:09:08 blogan: I don't fully understand it either but mlavalle has been through a similar change for DNS. I have some memories of reviewing that. 15:09:37 As I recall, mlavalle didn't think it was as bad as it first looked. Is that right mlavalle ? 15:09:58 carl_baldwin: it is really easy 15:10:09 carl_baldwin: but maybe blogan has a point 15:10:22 mlavalle: i probably dont, i'm more ignorant right now 15:10:37 mlavalle: Could you elaborate? 15:10:45 i was thinking it'd be more like a service plugin 15:11:02 the way I used th extension manager (and the way I understand it) the extension manager allows you to process additional attributes for existing top resources 15:11:23 Thats what my understanding is as well ... ^^ 15:11:32 mlavalle: it allows to extend existing resources yes, but something still has to handle it 15:12:00 carl_baldwin: are you adding create_segment, update_segment, etc methods to ml2? 15:12:30 mlavalle: Later on, those will come. 15:12:49 in that case the extension manager will be useful 15:13:11 so, the extension manager is for ml2, right? 15:13:22 xiaohhui: yes 15:13:24 ohhh ml2 extensions 15:13:58 carl_baldwin: and the extension manager will allow you to add segment related functionality to existing top resouces 15:14:01 * blogan finally put 1 and 1 together 15:14:31 carl_baldwin: while developing l2 adjacency, I also was thinking how to make all the extensions work in a single file 15:14:34 xiaohhui, blogan: neutron/plugins/ml2/extensions 15:14:46 mlavalle: yeah i was thinking of api extensions 15:15:51 but the segment now is as a first class object, we will create/delete it in ml2 directly, will the extension manager still apply? 15:15:51 in any case, is not difficult at all. not worst than a mixin 15:16:13 mlavalle: Interesting. I might have to pick your brain on this once I get the IPAM changes up for review. 15:16:22 xiaohhui: yeah that is why I am making the distinction 15:16:45 reedip__: I might be able to provide some assistance once I get over the learning curve myself. 15:17:18 xiaohhui: we are going to add create, update, etc methods to ml2. Just for that, we might not need an extension 15:17:18 This discussion has given me a good starting point. I hope to get to it tomorrow. 15:17:47 carl_baldwin: okay, I think review would be the best way to move forward 15:17:48 i look forward to learning about it too 15:18:11 OK, let's move on and plan to get to that in review later this week. 15:18:22 #topic Associate Subnets to Segments and IPAM 15:18:52 I'm still working this. I have it basically working in my sandbox but I have a bunch of UTs to fix. 15:19:19 Well I am interested in picking this task up 15:19:57 Basically, what I did was I added a way to pass the IPAM driver a list of subnet ids instead of just one. That way the driver can optimize. But, identifying the candidate subnets will still be in Neutron. 15:20:39 tonytan4ever: I will welcome your feedback on the patch when I post it for review. From there, maybe we can work on a way for you to help it continue to move forward. 15:21:12 sounds like a good plan. I will look at the PR once it is ready 15:21:32 I will reset my goal to get this posted by the end of the day today. 15:22:27 cool. 15:22:29 tonytan4ever: Thanks, I'll set the topic to "bp/routed-networks" so it should be easy to find once it is up. Watch for it in about 24 hours. 15:22:48 Cool. I will keep an eye on it. 15:22:57 That's all I have on this. 15:23:05 #topic Nova Scheduler 15:23:17 mlavalle: Hi. I think we've made some progress on this. 15:23:30 yes, we made great progress on this 15:24:13 esentially we wanted to get guidance / agreement from jaypipes on how to handle a couple of use cases between Nova resource pools and Neutron 15:24:16 I ran our thoughts about Neutron remembering at what point a port got its IP address (deferred or at port create) by armax. 15:24:36 armax pointed out some synergy with that idea and this blueprint: 15:24:37 https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address 15:25:49 great, will take a look and compare to what we discussed yesterday with Jay 15:25:56 In that blueprint, someone suggested a tri-state flag on the port to tell if the IP address will be 1) assigned right away, 2) deferred, or 3) never assigned. 15:26:23 that starts sounding to something we might use 15:26:28 mlavalle: Given this data on the port, we can derive what we need to know about the port when Nova goes to unbind the port. 15:26:47 yeah, I'll dig in :-) 15:26:48 It was a very astute observation by armax, our fearless leader. 15:27:10 he is always astute... especially in Gerrit 15:28:18 In a way, this gives us a head start in learning what obstacles we would run in to trying to get deferred IP allocation working with Nova. 15:28:59 From a different more pessimistic perspective, it does look like a little bit more work. 15:29:25 yes 15:29:36 mlavalle: Anyway, let's make sure that we can make that blueprint successful and I think we'll get what we need out of it. 15:29:43 I've assigned it to myself. 15:29:47 the good news is that we are uncovering this hurdles early in the game 15:29:53 mlavalle: ++ 15:30:22 I think the logs of the discussion would be very valuable .... 15:30:31 Anything else related to Nova? 15:31:01 mlavalle: ^ 15:31:07 carl_baldwin: did you have a chance to talk to armax about discussing routed networks in the jont session with Nova in Austin? 15:31:24 mlavalle: Ah, yes we did discuss that a bit. 15:31:52 He was aware of the session and the time slot and this is on the top of his list for that session. 15:32:01 ++ 15:32:31 that's what we need, especially since this sesion goes right after the Nova team discusses the scheduler 15:33:01 I'm actually feeling pretty good about the decision to keep track of those use cases in Neutron and adjusting the resource pools in Nova. 15:33:10 it was setup this way by mriedem to lead to the routed networks conversation 15:33:51 We're going to have to have a pretty good idea about how we're going to manage host aggregates and resource pools in Nova. 15:33:52 mlavalle, carl_baldwin: was that on the schedule armax posted yesterday? 15:33:56 the joint nova sessions? 15:34:16 blogan: no, it is in the nova schedule 15:34:25 mlavalle: okay good to know 15:35:01 carl_baldwin: the other thing I want to mention to the team is that the Newton spec for generic pools resources is up for review here: 15:35:09 blogan: Looks like our sessions start later that day. 15:35:10 #link https://review.openstack.org/#/c/300176/ 15:35:37 mlavalle: Thanks, I'll read through it. 15:35:50 we need this spec to get off the ground on the Nova side for our work on routed networks to move ahead 15:36:16 mlavalle: ++ 15:36:38 so we can use all the help we can get 15:37:01 Yes. 15:37:13 mlavalle: Anything else to discuss on this topic? 15:37:25 that's it for this week. we can move on 15:37:36 #topic Host / Segment Mapping 15:37:56 hi again 15:37:59 mlavalle: You're a busy guy 15:38:19 so I've been reviewing https://review.openstack.org/#/c/205631/33 since carl_baldwin pointed me to it 15:38:42 I definitely learned a bit from it 15:39:44 we can re use check_segment_for_agent in SimpleAgentMechanismDriverBase 15:40:22 to decide on host segment mapping on data coming from the agents 15:41:11 and then we might refactor the work in https://review.openstack.org/#/c/205631/33 to help that woprk to scale up better 15:41:22 this looks very similar to the dhcp agent scheduling for a segment too 15:41:24 mlavalle: That sounds pretty good. 15:41:43 the only de-tour we will have to take is with the SR-IOV mechanism agent 15:42:05 blogan: Yes, it is very related. In fact, it might be a good place to jump in and help things along. 15:42:21 carl_baldwin: definitely 15:42:23 it wasn't originally immplemented inheriting from SimpleAgentMechanismDriverBase 15:42:50 so it doesn't inherit check_segment_for_agent 15:43:16 the reason is that the SR-IOV driver originbally had the option to run without agent 15:43:27 but that option was eliminated in Mitaka 15:43:37 mlavalle: interesting 15:44:26 I checked with irenab this morning (the SR-IOV implementer) and she doesn't see any problem in having this mechanism driver inherit from SimpleAgentMechanismDriverBase 15:44:56 I will start a patch to do just that 15:45:11 mlavalle: Great, I'm happy to be a reviewer. blogan you too? 15:45:40 with that all the in tree mechanism drivers will have a uniform interface that we will leverage for host segment mapping and then improve the dhcp agent work 15:45:55 carl_baldwin: yes! 15:46:18 carl_baldwin: I thnk this is good progress report for this week :-) 15:46:45 mlavalle: great! 15:46:59 #topic Create / delete segment in ML2 15:47:21 xiaohhui: hi, I'm not sure you can do much with this until I figure out what to do with the basic CRUD patch. 15:47:35 yeah, 15:48:11 I added a new patch, the code looks good from DB's view 15:48:34 But I am afraid it will need change based on your change on basic CRUD 15:49:03 One thing to make sure, we will not support update for segment, right? 15:49:34 if name and description are added then update will be supported 15:49:48 I think reedip was working on that 15:49:51 xiaohhui: I don't think so for the existing attributes. We might support it for the name attribute. But, that shouldn't be much of a problem I don't think. 15:50:19 rtheis_: Right, and description . 15:50:25 my patch is STUCK 15:50:51 reedip__: Mine too. ;) 15:51:07 OK, I can continue to look into to see if there is any issue with the real functionality, now I only tried with DB data change. 15:51:36 I think that will be useful even if the code might change for the extension manager. 15:51:43 dont know why ...aLL: care to give some help ? https://review.openstack.org/293305 ? 15:52:30 reedip__: I've got to prioritize the preceding patch adding the basic CRUD. It will need some rework. 15:52:39 xiaohhui: ack 15:52:48 xiaohhui: I think you're right. 15:53:02 carl_baldwin :syn ack... 15:53:10 I think that is all for this work 15:53:20 reedip__: Thanks. 15:53:27 reedip__: i think that should be a new extension 15:53:41 api extension 15:53:46 blogan: Why a new extension? 15:54:23 blogan; I dont think so, but please let me know ur reasons for the same? 15:54:24 oh god nvm dont mind me 15:54:45 I think u r still in the extension Universe .... 15:54:47 i was thinking it was an older extension but realized it was the one just added 15:54:56 blogan: :) 15:54:58 too early for me, carry on 15:55:16 blogan: After I asked I realized that's probably what you were thinking. 15:55:29 I think we're safe to keep this extension open until the release. 15:55:43 Let's just skip right to Open Agenda. 15:55:44 carl_baldwin: yep! 15:55:47 #topic Open Agenda 15:56:27 Anything on the client, DHCP, or anything else? 15:56:34 3.5 minutes remaining. 15:56:36 so i've been ramping up on the dhcp agent stuff, just learing at this point 15:57:19 nothing on neutronclient , WIP for l2 publisjhed, the name/desc patch is stuck but needs API tests rewritten I guess 15:57:20 osc client patches were updated to align with API changes 15:57:36 reedip__: Thanks. 15:57:39 who is someone who knows a lot about the dhcp agent parts that I could ask questions to whenever I need to? 15:57:39 still a WIP but good progress 15:57:44 rtheis_: Thanks! 15:57:52 yw 15:58:02 check the Lieutenant 15:58:05 there is a patch in networking-ovn to read the data that routed networks need 15:58:06 blogan : 15:58:17 blogan: ZZelle might be a good one. mlavalle too by now. 15:58:31 id rather nto talk to mlavalle anymore 15:58:40 did i say that out loud? 15:58:45 blogan: i'd buy you luncj ;-) 15:58:47 * blogan loves mlavalle 15:58:53 blogan: I'm always looking for opportunities to talk to mlavalle 15:58:54 lunch^^^ 15:59:15 carl_baldwin: you're a masochist i see 15:59:35 who said there is no such thing as a free lunch :P 15:59:59 Well, we've got seconds left ... 16:00:03 #endmeeting