On Wed, Jun 6, 2012 at 8:29 PM, Rami Cohen wrote:
> 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 t
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,
Ra
On Wed, Jun 6, 2012 at 11:35 AM, Rami Cohen 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 Qu
On Wed, 2012-06-06 at 21:35 +0300, Rami Cohen 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 Qu
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
5 matches
Mail list logo
