James has run into an issue implementing the multi-hypervisor spec
which we're hoping to use to reduce infrastructure overheads by
deploying OpenStack control plane services in VMs, without requiring
dedicated VM hypervisor machines in the deploy cloud.

The issue we've hit is that the Neutron messages for VIF plugging are
sent to the Neutron agent with an exactly matching hostname to the
Nova-compute process. However, we have unique hostnames for the
nova-compute processes on one machine (one for -kvm, one for -docker,
one for -ironic etc) for a variety of reasons: so we can see if all
the processes are up, so that we don't get messages for the wrong
process from nova-api etc.

I think a reasonable step might be to allow the agent host option to
be a list - e.g.


we'd just make it listen to all the nova-compute hostnames we may have
on the machine.
That seems like a fairly shallow patch to me: add a new hosts option
with no default, change the code to listen to N queues when hosts is
set, and to report state N times as well (for consistency).
Alternatively, with a DB migration, we could record N hosts against
one agent status.

Alternatively we could run N ovs-agents on one machine (with a
separate integration bridge each), but I worry that we'd encounter
unexpected cross-chatter between them on things like external bridge


For now, we're going to have to run with a limitation of only one
vif-plugging hypervisor type per machine - we'll make the agent
hostname match that of the nova compute that needs VIFs plugged ;)


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to