<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 4:17 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
James has run into an issue implementing the multi-hypervisor spec<br>
(<a href="http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/tripleo-juno-deploy-cloud-hypervisor-type.rst" target="_blank">http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/tripleo-juno-deploy-cloud-hypervisor-type.rst</a>)<br>


which we're hoping to use to reduce infrastructure overheads by<br>
deploying OpenStack control plane services in VMs, without requiring<br>
dedicated VM hypervisor machines in the deploy cloud.<br>
<br>
The issue we've hit is that the Neutron messages for VIF plugging are<br>
sent to the Neutron agent with an exactly matching hostname to the<br>
Nova-compute process. However, we have unique hostnames for the<br>
nova-compute processes on one machine (one for -kvm, one for -docker,<br>
one for -ironic etc) for a variety of reasons: so we can see if all<br>
the processes are up, so that we don't get messages for the wrong<br>
process from nova-api etc.<br></blockquote><div><br></div><div>So you are running multiple nova-computes on a single node? This goes against the model that nova is operating under. Instead of hacking a workaround, if we think this is a use case nova/openstack should support, why not have that discussion before deciding that the best solution is a shallow patch.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think a reasonable step might be to allow the agent host option to<br>
be a list - e.g.<br>
<br>
 [DEFAULT]<br>
 hosts={{nova.compute_hostname}}-libvirt,{{nova.compute_hostname}}-docker<br>
<br>
we'd just make it listen to all the nova-compute hostnames we may have<br>
on the machine.<br>
That seems like a fairly shallow patch to me: add a new hosts option<br>
with no default, change the code to listen to N queues when hosts is<br>
set, and to report state N times as well (for consistency).<br>
Alternatively, with a DB migration, we could record N hosts against<br>
one agent status.<br>
<br>
Alternatively we could run N ovs-agents on one machine (with a<br>
separate integration bridge each), but I worry that we'd encounter<br>
unexpected cross-chatter between them on things like external bridge<br>
flows.<br>
<br>
Thoughts?<br>
<br>
For now, we're going to have to run with a limitation of only one<br>
vif-plugging hypervisor type per machine - we'll make the agent<br>
hostname match that of the nova compute that needs VIFs plugged ;)<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>