16:05:07 #startmeeting networking_ml2 16:05:09 Meeting started Wed Aug 17 16:05:07 2016 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:13 The meeting name has been set to 'networking_ml2' 16:05:24 #topic: Agenda 16:05:25 #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_August_17.2C_2016 16:05:40 #topic: Announcements 16:06:15 There is neutron mid-cycle going on this week - most of the people are there, hence, we do not have many people here 16:06:51 here is the link if anybody is interested - https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems 16:07:04 I have added the remote dial-in information as well 16:07:26 Now I am going to skip the rest of the agenda and go to Open Discussion 16:07:33 #topic: Open Discussion 16:07:45 thanks for the mid-cycle link 16:07:50 ok 16:07:58 rkukura : during a discussion, this question came up 16:08:12 so, I thought I bring it up here for clarification 16:09:02 Somebody proposed to remove the create_port pre/post commit methods in mech driver as ML2 plugin calls update_port pre/post 16:09:25 That makes little sense to me 16:09:51 the update calls are related to port binding, which may or may not be attempted immediately after the create 16:10:31 if the port is created without a binding:host_id value, I would not expect the update calls to be made. But I could be missing something. 16:10:47 Well, I was told that ML2 plugin automatically calls update port immediately after create port - if the vif_details is unbound 16:11:18 It can only try to bind if binding:host_id is set 16:11:57 Lets take a scenario and walk through - 16:12:07 I guess I’d agree that certain MDs would only need to pay attention to the updates 16:12:44 Say somebody creates a neutron port (and does not provide host-id) 16:12:58 and later a nova boot is issued 16:13:23 Sukhdev: If create port fails, update port will not occur. 16:13:54 Hi cbouch! 16:14:01 at this time a bind_port and update_port will issued (with host-id) - now MD can implicitly process create_port 16:14:09 sukhdev: unlike update port which continually retries on failure 16:14:33 rkukura: Hi Bob. 16:15:23 In this scenario, I expect the port_create to be processed, and then a port_update that sets the binding:host_id, and then a 2nd port_update the sets the results of the port binding. 16:15:27 cbouch : right -for a sec, ignore the failure path - and see if the flow is correct 16:16:24 Here is the kicker (and issue) - create_port does not carry phynet info, but, the update port carries this information. 16:16:39 Until the update port, MD does not know if it is suppose to process the create port 16:17:16 Sukhdev: What do you mean by “phynet info”? 16:17:55 ML2 does not specify what an MD might need to do when a port is created or bound - that is up to the individual MD 16:17:55 when an MD binds the port, it sets the physnet info in the context, which gets passed in update port 16:18:33 Say (for example) Cisco and Arista - two MDs are in play 16:18:43 The network’s segments are available when the port is created. The segment bound is available in the update_port that commits the binding results 16:19:00 Cisco manages one tor and Arista manages another tor 16:19:08 ok 16:19:42 Cisco is only interested in managing one tor (which is known from the physnet) information - which is not available in create_port 16:20:19 Sukhdev: right 16:20:32 so, when Cisco MD binds port, it will set that infromation - update port will go to both MDs, Arista will ignore and Cisco will process 16:20:35 So the Cisco MD should do nothing in create_port 16:20:55 right - that is the argument being presented 16:21:04 Right, but MDs should use the result of the binding in that update_port 16:21:09 in fact both MDs should do nothing in this case in create_port 16:21:26 Sukhdev: That is often the case, but not always 16:21:49 Some MDs may need to know about the ports before any binding occurs. 16:22:15 I completely agree that most MDs don’t need to do anything in create_port 16:23:01 rkukura : yup, that is the point of discussion/clarification 16:23:19 Sounds clear to me 16:23:39 Is anyone arguing the the create_port calls should be removed from ML2? 16:24:24 rkukura : not from ML2, but, from MD 16:24:32 cbouch : do you agree? 16:25:14 If an MD doesn’t have anything useful to do in any particular driver API call, it simply does not implement that call. 16:25:17 We actually use create_port. 16:25:39 If unable to contact switch, we fail the transaction to avoid constant updates. 16:25:55 cbouch : how do you know if a given physnet belongs to your MD in create_port ? 16:26:28 cbouch : right - that is a good point from the failure management point of view 16:26:34 I'll have to check the code. I've been away for awhile 16:26:44 cbouch : me too :-) 16:27:44 rkukura : just want to clarify/recap with the help of a different scenario - to make sure this works 16:28:21 Back when most MDs were in-tree, I had hoped we’d all keep an eye on each other and ensure drivers played nicely together in heterogeneous deployment scenarios, but it hasn’t worked out that way :| 16:28:48 rkukura : say somebody creates a port with no intent to attach a VM to it - i..e. there will not be a nova boot 16:29:14 Sukhdev: sure 16:29:24 so, only create_port is issued, but, host-id is present in the create_port 16:29:44 Suhkdev: We know create_port is ours due to host_id. 16:30:43 will ML2 automatically call the update_port? is this always guranteed (as long as host-id is present) 16:31:08 cbouch : right 16:31:26 Carol, are you saying that your driver will configure the switch during create_port when host_id is set, even before port binding has occured? 16:32:29 We don't configure the switch during create_port 16:32:41 just make sure the switch is ready for config 16:32:42 Sukhdev: I’m pretty sure that if binding:host_id is set during the create, but port binding fails, port_update will be called changing binding:vif_type from “unbound” to “binding failed” 16:32:52 Then NACK is not ready 16:33:14 then NACK if not ready 16:33:44 cbouch: that makes sense 16:35:08 rkukura : so, whether binding fails or succeeds, port_update will called regardless as part of create_port 16:35:25 I’m a bit concerned about failing the port_create based on switch status. Even if one MD is not going to work, some other MD might be able to bind. 16:36:09 Sukhdev: port_update will not be called if the port_create does not enable binding of the port, i.e. when binding:host_id is not set. 16:36:54 rkukura : in my scenario, I am assuming host_id is set in create_port 16:37:13 rkukura: I'll share this with my peer who proposed port_create failure. 16:37:37 cbouch: thanks 16:38:04 cbouch : right, otherwise, it will not work in the scenario we discussed above 16:38:13 As I recall, setting binding:host_id is all that is necessary for ML2 to try to bind the port, but I’m not 100% certain 16:38:28 ok. My peer is on PTO. Will share this with him 16:38:40 on vacation 16:39:00 rkukura: I think you are right - host_id is all that is needed for binding the port 16:41:24 cbouch rkukura : so, to recap, in order to support multi-vendor deployments, the MDs should ignore create_port and perform implicit create_port during update_port (or bind_port) if a port belong to the MD 16:41:53 I’d state it a bit differently 16:43:37 For a ToR switch MD that does not do HPB, the MD should configure the switch during port_update when the binding:host_id indicates successful binding to a host connected to that switch and the bound segment is one the switch handles. 16:44:56 I’d wordsmith that a bit more, but I think we are all on the same page 16:46:15 yes. Will investigate further as this creates a problem for us. 16:47:51 Right, we are on the same page in terms of understanding of the issue - I would wordsmith your statement to remove the reference to HPB - it should be true regardless of HPB 16:47:59 It would be nice if we could put some guidelines in the devref for ML2 driver writers that covered details like these, especially what’s need to allow heterogeneous deployments. 16:48:54 With HPB, the ToR MDs role in the binding is more explicit - the MD will be listed in the binding_levels during the port_update, and the MD should not configure the switch if it is not listed. 16:50:52 rkukura : I see - that is a good point. So, to determine if it needs to bind the port, it should look into phynet and to update the port, it should look for itself in binding_levels 16:51:38 right 16:51:50 makes sense 16:52:01 this should really be documented :-) 16:52:28 And just because it called continue_binding() from its bind_port(), it cannot assume that this is the binding the succeeded. It really shouldn’t consider the binding real until it sees it in update_port 16:52:54 s/binding the succeeded/binding that succeeded/ 16:53:31 rkukura +1 16:53:48 So the one takeway from this discussion is really that its the update_port calls after succesful binding that are definitive 16:54:32 rkukura : right - that is what I was trying to confirm, and, hence, MD can safely ignore create_port 16:54:53 MDs might do useful things during create_port and during bind_port, but there are no guarantees they will handle traffic for that port until the update_port 16:54:55 I mean the MD that manages switches 16:55:28 * Sukhdev time check - 5 min 16:56:54 Anything else? 16:57:06 I think we are good 16:57:15 we reached a good conclusion 16:57:31 if nothing else, we are done 16:57:41 thanks for participation in the discussion 16:57:42 thanks Sukhdev! 16:57:46 bye 16:57:49 bye 16:57:52 #endmeeting