16:05:07 <Sukhdev> #startmeeting networking_ml2
16:05:09 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:13 <openstack> The meeting name has been set to 'networking_ml2'
16:05:24 <Sukhdev> #topic: Agenda
16:05:25 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_August_17.2C_2016
16:05:40 <Sukhdev> #topic: Announcements
16:06:15 <Sukhdev> 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 <Sukhdev> here is the link if anybody is interested - https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
16:07:04 <Sukhdev> I have added the remote dial-in information as well
16:07:26 <Sukhdev> Now I am going to skip the rest of the agenda and go to Open Discussion
16:07:33 <Sukhdev> #topic: Open Discussion
16:07:45 <rkukura> thanks for the mid-cycle link
16:07:50 <rkukura> ok
16:07:58 <Sukhdev> rkukura : during a discussion, this question came up
16:08:12 <Sukhdev> so, I thought I bring it up here for clarification
16:09:02 <Sukhdev> 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 <rkukura> That makes little sense to me
16:09:51 <rkukura> the update calls are related to port binding, which may or may not be attempted immediately after the create
16:10:31 <rkukura> 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 <Sukhdev> Well, I was told that ML2 plugin automatically calls update port immediately after create port - if the vif_details is unbound
16:11:18 <rkukura> It can only try to bind if binding:host_id is set
16:11:57 <Sukhdev> Lets take a scenario and walk through -
16:12:07 <rkukura> I guess I’d agree that certain MDs would only need to pay attention to the updates
16:12:44 <Sukhdev> Say somebody creates a neutron port (and does not provide host-id)
16:12:58 <Sukhdev> and later a nova boot is issued
16:13:23 <cbouch> Sukhdev:  If create port fails, update port will not occur.
16:13:54 <rkukura> Hi cbouch!
16:14:01 <Sukhdev> at this time a bind_port and update_port will issued (with host-id) - now MD can implicitly process create_port
16:14:09 <cbouch> sukhdev: unlike update port which continually retries on failure
16:14:33 <cbouch> rkukura:  Hi Bob.
16:15:23 <rkukura> 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 <Sukhdev> cbouch : right -for a sec, ignore the failure path - and see if the flow is correct
16:16:24 <Sukhdev> Here is the kicker (and issue) - create_port does not carry phynet info, but, the update port carries this information.
16:16:39 <Sukhdev> Until the update port, MD does not know if it is suppose to process the create port
16:17:16 <rkukura> Sukhdev: What do you mean by “phynet info”?
16:17:55 <rkukura> 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 <Sukhdev> when an MD binds the port, it sets the physnet info in the context, which gets passed in update port
16:18:33 <Sukhdev> Say (for example) Cisco and Arista - two MDs are in play
16:18:43 <rkukura> 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 <Sukhdev> Cisco manages one tor and Arista manages another tor
16:19:08 <rkukura> ok
16:19:42 <Sukhdev> 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 <rkukura> Sukhdev: right
16:20:32 <Sukhdev> 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 <rkukura> So the Cisco MD should do nothing in create_port
16:20:55 <Sukhdev> right - that is the argument being presented
16:21:04 <rkukura> Right, but MDs should use the result of the binding in that update_port
16:21:09 <Sukhdev> in fact both MDs should do nothing in this case in create_port
16:21:26 <rkukura> Sukhdev: That is often the case, but not always
16:21:49 <rkukura> Some MDs may need to know about the ports before any binding occurs.
16:22:15 <rkukura> I completely agree that most MDs don’t need to do anything in create_port
16:23:01 <Sukhdev> rkukura : yup, that is the point of discussion/clarification
16:23:19 <rkukura> Sounds clear to me
16:23:39 <rkukura> Is anyone arguing the the create_port calls should be removed from ML2?
16:24:24 <Sukhdev> rkukura : not from ML2, but, from MD
16:24:32 <Sukhdev> cbouch : do you agree?
16:25:14 <rkukura> 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 <cbouch> We actually use create_port.
16:25:39 <cbouch> If unable to contact switch, we fail the transaction to avoid constant updates.
16:25:55 <Sukhdev> cbouch : how do you know if a given physnet belongs to your MD in create_port ?
16:26:28 <Sukhdev> cbouch : right - that is a good point from the failure management point of view
16:26:34 <cbouch> I'll have to check the code.  I've been away for awhile
16:26:44 <Sukhdev> cbouch : me too :-)
16:27:44 <Sukhdev> rkukura : just want to clarify/recap with the help of a different scenario - to make sure this works
16:28:21 <rkukura> 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 <Sukhdev> 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 <rkukura> Sukhdev: sure
16:29:24 <Sukhdev> so, only create_port is issued, but, host-id is present in the create_port
16:29:44 <cbouch> Suhkdev:  We know create_port is ours due to host_id.
16:30:43 <Sukhdev> will ML2 automatically call the update_port? is this always guranteed (as long as host-id is present)
16:31:08 <Sukhdev> cbouch : right
16:31:26 <rkukura> 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 <cbouch> We don't configure the switch during create_port
16:32:41 <cbouch> just make sure the switch is ready for config
16:32:42 <rkukura> 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 <cbouch> Then NACK is not ready
16:33:14 <cbouch> then NACK if not ready
16:33:44 <Sukhdev> cbouch: that makes sense
16:35:08 <Sukhdev> rkukura : so, whether binding fails or succeeds, port_update will called regardless as part of create_port
16:35:25 <rkukura> 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 <rkukura> 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 <Sukhdev> rkukura : in my scenario, I am assuming host_id is set in create_port
16:37:13 <cbouch> rkukura:  I'll share this with my peer who proposed port_create failure.
16:37:37 <rkukura> cbouch: thanks
16:38:04 <Sukhdev> cbouch : right, otherwise, it will not work in the scenario we discussed above
16:38:13 <rkukura> 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 <cbouch> ok. My peer is on PTO. Will share this with him
16:38:40 <cbouch> on vacation
16:39:00 <Sukhdev> rkukura: I think you are right - host_id is all that is needed for binding the port
16:41:24 <Sukhdev> 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 <rkukura> I’d state it a bit differently
16:43:37 <rkukura> 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 <rkukura> I’d wordsmith that a bit more, but I think we are all on the same page
16:46:15 <cbouch> yes.  Will investigate further as this creates a problem for us.
16:47:51 <Sukhdev> 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 <rkukura> 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 <rkukura> 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 <Sukhdev> 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 <rkukura> right
16:51:50 <Sukhdev> makes sense
16:52:01 <Sukhdev> this should really be documented :-)
16:52:28 <rkukura> 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 <rkukura> s/binding the succeeded/binding that succeeded/
16:53:31 <Sukhdev> rkukura +1
16:53:48 <rkukura> So the one takeway from this discussion is really that its the update_port calls after succesful binding that are definitive
16:54:32 <Sukhdev> rkukura : right - that is what I was trying to confirm, and, hence, MD can safely ignore create_port
16:54:53 <rkukura> 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 <Sukhdev> I mean the MD that manages switches
16:55:28 * Sukhdev time check - 5 min
16:56:54 <rkukura> Anything else?
16:57:06 <Sukhdev> I think we are good
16:57:15 <Sukhdev> we reached a good conclusion
16:57:31 <Sukhdev> if nothing else, we are done
16:57:41 <Sukhdev> thanks for participation in the discussion
16:57:42 <rkukura> thanks Sukhdev!
16:57:46 <Sukhdev> bye
16:57:49 <rkukura> bye
16:57:52 <Sukhdev> #endmeeting