Open Stack

Hi Kevin, thanks for your input! See my comments in line



-- 
-----
Andreas (IRC: scheuran) 

On Di, 2016-04-12 at 04:12 -0700, Kevin Benton wrote:
> We can't change the host_id until after the migration or it will break
> l2pop other drivers that use the host as a location indicator (e.g.
> many top of rack drivers do this to determine which switch port should
> be wired up).

I was assuming something like that. Thanks for clarification.


> There is already a patch that went in to inform Neutron of the
> destination host here for proactive DVR
> wiring: https://review.openstack.org/#/c/275420/ During this port
> update phase, we can validate the destination host is 'bindable' with
> the given port info and fail it otherwise. This should block Nova from
> continuing.
> 
> 
> However, we have to figure out how ML2 will know if something is
> 'bindable'. The only interface we have right now is bind_port. It is
> possible that we can do a faked bind_port attempt using what the port
> host_id would look like after migration. It's made clear in the ML2
> driver API that bind_port results may not be
> committed: https://github.com/openstack/neutron/blob/4440297a2ff5a6893b748c2400048e840283c718/neutron/plugins/ml2/driver_api.py#L869

Agree, that was one of the alternatives I had in mind as well. The
introduced API looks good and could be used I think!

> So the workflow would be something like:
> * Nova calls Neutron port update with the destination host in the
> binding details
> * In ML2 port update, the destination host is placed into a copy of
> the port in the host_id field and bind_port is called.
> * If bind_port is unsuccessful, it fails the port update for Nova to
> prevent migration.
> * If bind_port is successful, the results of the port update are
> committed (with the original host_id and the new host_id in the
> destination_host field).
Ideally the update host would then return the copy binding information
instead of the real ones. Doing so, I could use this data to modifiy the
domain.xml before migration with the relevant information.
> * Workflow continues as normal here.
> 
> 
> So this heavily exploits the fact that bind_port is supposed to be
> mutation-free in the ML2 driver API. We may encounter drivers that
> don't follow this now, but they are already exposed to other bugs if
> they mutate state so I think the onus would be on them to fix their
> driver.
> 
> 
> Cheers,
> Kevin Benton
> 

>