[openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

Ian Wells ijw.ubuntu at cack.org.uk
Fri Jul 19 22:37:38 UTC 2013


> [arosen] - sure, in this case though then we'll have to add even more
> queries between nova-compute and quantum as nova-compute will need to query
> quantum for ports matching the device_id to see if the port was already
> created and if not try to create them.

The cleanup job doesn't look like a job for nova-compute regardless of the rest.

> Moving the create may for other reasons be a good idea (because compute
> would *always* deal with ports and *never* with networks - a simpler API) -
> but it's nothing to do with solving this problem.
>
> [arosen] - It does solve this issue because it moves the quantum port-create
> calls outside of the retry schedule logic on that compute node. Therefore if
> the port fails to create the instance goes to error state.  Moving networks
> out of the nova-api will also solve this issue for us as the client then
> won't rely on nova anymore to create the port. I'm wondering if creating an
> additional network_api_class like nova.network.quantumv2.api.NoComputeAPI is
> the way to prove this out. Most of the code in there would inherit from
> nova.network.quantumv2.api.API .

OK, so if we were to say that:

- nova-api creates the port with an expiry timestamp to catch orphaned
autocreated ports
- nova-compute always uses port-update (or, better still, have a
distinct call that for now works like port-update but clearly
represents an attach or detach and not a user-initiated update,
improving the plugin division of labour, but that can be a separate
proposal) and *never* creates a port; attaching to an
apparently-attached port attached to the same instance should ensure
that a previous attachment is destroyed, which should cover the
multiple-schedule lost-reply case
- nova-compute is always talked to in terms of ports, and never in
terms of networks (a big improvement imo)
- nova-compute attempts to remove autocreated ports on detach
- a cleanup job in nova-api (or nova-conductor?) cleans up expired
autocreated ports with no attachment or a broken attachment (which
would catch failed detachments as well as failed schedules)

how does that work for people?  It seems to improve the internal
interface and the transactionality, it means that there's not the
slightly nasty (and even faintly race-prone) create-update logic in
nova-compute, it even simplifies the nova-compute interface - though
we would need to consider how an upgrade path would work, there; newer
API with older compute should work fine, the reverse not so much.
-- 
Ian.



More information about the OpenStack-dev mailing list