<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 12:28 PM, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">><br></div><div class="im">
> @Mike - I think we'd still want to leave nova-compute to create the tap<br>
> interfaces and sticking  external-ids on them though.<br>
<br>
</div>It also seems nova-compute should call port-update to set<br>
binding:host_id and then use the returned binding:vif_type, since the<br>
vif_type might vary depending on the host, at least with ml2. The Arista<br>
top-of-rack switch hardware driver functionality also depends on the<br>
binding:host_id being set.<br>
<br>
-Bob<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Hmmm, is that really nova-compute's job? Again, that seems to be the networking abstraction's job to me. We have all these quantum agents, they have the device_id (instance_uuid). Why not have a quantum component (agent maybe?) query nova for the host_id and then it calls port-update?</div>
<div style><br></div><div style>-Mike</div></div><br></div></div>