Open Stack

Dan,
I totally agree that the driver should be thin and focus on VM
provision/termination.
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.

Best Regards,
RamiC


On Thu, Jun 7, 2012 at 12:08 AM, Dan Wendlandt <dan at nicira.com> wrote:

>
>
> On Wed, Jun 6, 2012 at 11:35 AM, Rami Cohen <ramic.home at gmail.com> wrote:
>
>> Hi,
>> 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.
>> 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.
>>
>
> Hi Rami,
>
> 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.
>
> However, I do want to make sure that the vif-plugging driver stays "thin"
> and focused primarily on connecting the vNIC to the switch.
>
> Dan
>
>
>
>>
>> RamiC
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


-- 
RamiC™
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120607/388272f8/attachment.html>