<div dir="ltr">Dan,<br>I totally agree that the driver should be thin and focus on VM provision/termination.<br>While ii may be looked unimportant, I just prefer that the quantum manager will determine both VIF and bridge name instead of using a convention that these names are extracted from the UUID.<br>
<br>Best Regards,<br>RamiC<br><br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 12:08 AM, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 6, 2012 at 11:35 AM, Rami Cohen <span dir="ltr"><<a href="mailto:ramic.home@gmail.com" target="_blank">ramic.home@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr">Hi,<br>While Quantum manager may communicate with compute nodes using a quantum
 agent, in some cases when Quantum is integrated with Nova, the agent 
may not be needed (while it can be used for enhanced services). In this 
cases, when the Quantum VIF driver (which is part of Nova compute) is 
used for VM provisioning/terminating/restarting utilizing the existing
 Nova infrastructure, it may be required to pass parameters from the 
quantum manager to the Quantum driver. Nevertheless, in current Nova 
architecture the Nova network does not pass the values returned from the
 quantum Manager to the compute nodes.<br>
I really think that passing the Quantum manager values to the Quantum 
VIF driver is really important for Quantum agent less implementation and
 it is quite an easy change to make.<br></div></blockquote><div><br></div></div></div><div>Hi Rami,</div><div><br></div><div>I see no problem with the vif-driver getting information returned from Quantum per-se.  In fact, tr3buchet is reworking the nova/quantum integration code and as a result some values from Quantum (e.g., allocated MAC + IP address) will most definitely be passed to the vif-driver.  </div>


<div><br></div><div>However, I do want to make sure that the vif-plugging driver stays "thin" and focused primarily on connecting the vNIC to the switch.</div><div><br></div><div>Dan</div><div><br></div><div> </div>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>RamiC
</div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>RamiC™<br>
</div>