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 > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
