Mailing List Archive

Rami,
Following the recent discussions on the mailing list regarding the responsibility of the VIF driver, seems that it should be very thin and network provisioning should be handled by Quantum Plugin Agent as in OpenvSwitch and LinuxBridge plugins.
I have similar need to get attributes for the attached network/ port and seems that the way to do it is via API extension.
You can see the details in the following mailing thread:
https://lists.launchpad.net/openstack/msg12716.html

Hope this helps,
Irena
From: netstack-bounces+irenab=mellanox.com@lists.launchpad.net [mailto:netstack-bounces+irenab=mellanox.com@lists.launchpad.net] On Behalf Of Rami Cohen
Sent: Tuesday, June 05, 2012 1:14 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] Nova & Quantum integration

Hi,
Is there any mechanism to pass some parameters from Quantum Manager to the Quantum VIF driver (that is part of the Nova compute)?
In particular, I saw that when Nova network calls Quantum API (create and attach ports) it ignores the return values sent from the quantum manager, so there is no formal way to reflect them back to the Nova compute.

Thanks,
RamiC

Hi,
As far as I understand the nova-network module treats the errors. Please
look at the trace - this is when deploying a new instance (via devstack)
and the quantum server is not available:

2012-06-05 07:42:09 DEBUG nova.network.quantum.quantum_connection
[req-f3a300fa-2fae-4438-9bc3-b6b78c53fc8d
762c85b0eae0430a89b9f1a2f3099dfa b3147572ff324a0fb6168c61a31d405a]
Connecting interface 4765b48e-624e-4fcc-93a6-669fbc731ec9 to net
77ea4e74-ea38-4834-ba16-20d2a9d6865d for default from (pid=4579)
create_and_attach_port
/opt/stack/nova/nova/network/quantum/quantum_connection.py:104
2012-06-05 07:42:09 DEBUG nova.network.quantum.quantum_connection
[req-f3a300fa-2fae-4438-9bc3-b6b78c53fc8d
762c85b0eae0430a89b9f1a2f3099dfa b3147572ff324a0fb6168c61a31d405a]
Quantum Client Request: POST
/v1.1/tenants/default/networks/77ea4e74-ea38-4834-ba16-20d2a9d6865d/ports.json
from (pid=4579) do_request
/opt/stack/nova/nova/network/quantum/client.py:183
2012-06-05 07:42:09 DEBUG nova.network.quantum.quantum_connection
[req-f3a300fa-2fae-4438-9bc3-b6b78c53fc8d
762c85b0eae0430a89b9f1a2f3099dfa b3147572ff324a0fb6168c61a31d405a]
{"port": {"state": "ACTIVE", "vm_id":
"4cfb94fc-e2cf-43f7-9b87-6ed1b3dbd01b", "nova_id": "nova",
"allowed_address_pairs": [], "rxtx_factor": 1.0}} from (pid=4579)
do_request /opt/stack/nova/nova/network/quantum/client.py:185
2012-06-05 07:42:09 ERROR nova.rpc.amqp [-] Exception during message
handling
2012-06-05 07:42:09 TRACE nova.rpc.amqp Traceback (most recent call last):
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/rpc/amqp.py", line 267, in _process_data
2012-06-05 07:42:09 TRACE nova.rpc.amqp rval =
self.proxy.dispatch(ctxt, version, method, **args)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/rpc/dispatcher.py", line 103, in dispatch
2012-06-05 07:42:09 TRACE nova.rpc.amqp return getattr(proxyobj,
method)(ctxt, **kwargs)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/network/quantum/manager.py", line 385, in
allocate_for_instance
2012-06-05 07:42:09 TRACE nova.rpc.amqp allowed_address_pairs=pairs)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/network/quantum/quantum_connection.py", line 108,
in create_and_attach_port
2012-06-05 07:42:09 TRACE nova.rpc.amqp resdict =
self.client.create_port(net_id, port_data, tenant=tenant_id)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/network/quantum/client.py", line 82, in with_params
2012-06-05 07:42:09 TRACE nova.rpc.amqp ret = self.func(instance,
*args, **kwargs)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/network/quantum/client.py", line 283, in create_port
2012-06-05 07:42:09 TRACE nova.rpc.amqp return
self.do_request("POST", self.ports_path % (network), body=body)
2012-06-05 07:42:09 TRACE nova.rpc.amqp File
"/opt/stack/nova/nova/network/quantum/client.py", line 213, in do_request
2012-06-05 07:42:09 TRACE nova.rpc.amqp "server. Got error: %s") % e)
2012-06-05 07:42:09 TRACE nova.rpc.amqp QuantumIOException: Unable to
connect to server. Got error: [Errno 111] ECONNREFUSED
2012-06-05 07:42:09 TRACE nova.rpc.amqp
2012-06-05 07:42:09 ERROR nova.rpc.common [-] Returning exception Unable
to connect to server. Got error: [Errno 111] ECONNREFUSED to caller

I assume that the nova-network will treat the REST error codes accordingly.
Thanks
Gary
On 06/05/2012 02:35 PM, Irena Berezovsky wrote:
>
> Rami,
>
> Following the recent discussions on the mailing list regarding the
> responsibility of the VIF driver, seems that it should be very thin
> and network provisioning should be handled by Quantum Plugin Agent as
> in OpenvSwitch and LinuxBridge plugins.
>
> I have similar need to get attributes for the attached network/ port
> and seems that the way to do it is via API extension.
>
> You can see the details in the following mailing thread:
>
> https://lists.launchpad.net/openstack/msg12716.html
>
> Hope this helps,
>
> Irena
>
> *From:*netstack-bounces+irenab=mellanox.com@lists.launchpad.net
> [mailto:netstack-bounces+irenab=mellanox.com@lists.launchpad.net] *On
> Behalf Of *Rami Cohen
> *Sent:* Tuesday, June 05, 2012 1:14 PM
> *To:* netstack@lists.launchpad.net
> *Subject:* [Netstack] Nova & Quantum integration
>
> Hi,
> Is there any mechanism to pass some parameters from Quantum Manager to
> the Quantum VIF driver (that is part of the Nova compute)?
> In particular, I saw that when Nova network calls Quantum API (create
> and attach ports) it ignores the return values sent from the quantum
> manager, so there is no formal way to reflect them back to the Nova
> compute.
>
> Thanks,
> RamiC
>

Irena,
In current Quantum/Nova Implementation and openvswitch plugin the VIF
driver performs the actual vif connectivity to the vswitch (using
'ovs-vsctl'). This make sense since it reuse existing Nova messaging
mechanism and the fact that the Nova compute is already deployed on each
node (so why to deploy, maintain and communicate with additional agent?). I
would think that the best way is to enable quantum to pass parameters to
the VIF driver.
What do you think?

RamiC

the Nova compute is already deployed on each host) the fact that the
parameters of quantum does not sent back to the driver

On Tue, Jun 5, 2012 at 2:35 PM, Irena Berezovsky <irenab@mellanox.com>wrote:

> Rami,****
>
> Following the recent discussions on the mailing list regarding the
> responsibility of the VIF driver, seems that it should be very thin and
> network provisioning should be handled by Quantum Plugin Agent as in
> OpenvSwitch and LinuxBridge plugins.****
>
> I have similar need to get attributes for the attached network/ port and
> seems that the way to do it is via API extension.****
>
> You can see the details in the following mailing thread: ****
>
> https://lists.launchpad.net/openstack/msg12716.html****
>
> ** **
>
> Hope this helps,****
>
> Irena****
>
> *From:* netstack-bounces+irenab=mellanox.com@lists.launchpad.net [mailto:
> netstack-bounces+irenab=mellanox.com@lists.launchpad.net] *On Behalf Of *Rami
> Cohen
> *Sent:* Tuesday, June 05, 2012 1:14 PM
> *To:* netstack@lists.launchpad.net
> *Subject:* [Netstack] Nova & Quantum integration****
>
> ** **
>
> Hi,
> Is there any mechanism to pass some parameters from Quantum Manager to the
> Quantum VIF driver (that is part of the Nova compute)?
> In particular, I saw that when Nova network calls Quantum API (create and
> attach ports) it ignores the return values sent from the quantum manager,
> so there is no formal way to reflect them back to the Nova compute.
>
> Thanks,
> RamiC
>
> ****
>



--
RamiC™

Rami,

A quantum agent configuring the vswitch can get very complex (especially
when adding things like security groups, QoS policies, etc. etc.). We do
not want to complicate Nova by having it perform all operations on the
vswitch.

Also, the Quantum agent may need to reconfigure the vswitch at any point,
resulting from a change made to the quantum API (e.g., putting a quantum
port in 'admin-down' state). Nova really only does anything network
related when a VM is created, destroyed, or restarted. Thus, we have nova
only do the absolute simplest networking step of creating the device
presenting the vNIC, and informing the vswitch about it (and the
corresponding tear-down).

The OVS + Linux Bridge plugins have agents that you could use as a model.

Dan


On Tue, Jun 5, 2012 at 10:22 AM, Rami Cohen <ramic.home@gmail.com> wrote:

> Irena,
> In current Quantum/Nova Implementation and openvswitch plugin the VIF
> driver performs the actual vif connectivity to the vswitch (using
> 'ovs-vsctl'). This make sense since it reuse existing Nova messaging
> mechanism and the fact that the Nova compute is already deployed on each
> node (so why to deploy, maintain and communicate with additional agent?). I
> would think that the best way is to enable quantum to pass parameters to
> the VIF driver.
> What do you think?
>



>
> RamiC
>
> the Nova compute is already deployed on each host) the fact that the
> parameters of quantum does not sent back to the driver
>
> On Tue, Jun 5, 2012 at 2:35 PM, Irena Berezovsky <irenab@mellanox.com>wrote:
>
>> Rami,****
>>
>> Following the recent discussions on the mailing list regarding the
>> responsibility of the VIF driver, seems that it should be very thin and
>> network provisioning should be handled by Quantum Plugin Agent as in
>> OpenvSwitch and LinuxBridge plugins.****
>>
>> I have similar need to get attributes for the attached network/ port and
>> seems that the way to do it is via API extension.****
>>
>> You can see the details in the following mailing thread: ****
>>
>> https://lists.launchpad.net/openstack/msg12716.html****
>>
>> ** **
>>
>> Hope this helps,****
>>
>> Irena****
>>
>> *From:* netstack-bounces+irenab=mellanox.com@lists.launchpad.net [mailto:
>> netstack-bounces+irenab=mellanox.com@lists.launchpad.net] *On Behalf Of *Rami
>> Cohen
>> *Sent:* Tuesday, June 05, 2012 1:14 PM
>> *To:* netstack@lists.launchpad.net
>> *Subject:* [Netstack] Nova & Quantum integration****
>>
>> ** **
>>
>> Hi,
>> Is there any mechanism to pass some parameters from Quantum Manager to
>> the Quantum VIF driver (that is part of the Nova compute)?
>> In particular, I saw that when Nova network calls Quantum API (create and
>> attach ports) it ignores the return values sent from the quantum manager,
>> so there is no formal way to reflect them back to the Nova compute.
>>
>> Thanks,
>> RamiC
>>
>> ****
>>
>
>
>
> --
> RamiC™
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dan,
Thanks for your quick and detailed response.
While I understand that the agent is used for enhanced services while the
driver is just for VM provisioning/destroying/restarting, I still think
that reflecting the values returned by quantum API to the Quantum driver
may be beneficial and it requires minimum effort (just returns the
parameters by Nova network to the Nova compute. In particular, it may save
a lot of (development and QA) effort when the agent is not needed.
What do you think?

RamiC


On Tue, Jun 5, 2012 at 9:30 PM, Dan Wendlandt <dan@nicira.com> wrote:

> Rami,
>
> A quantum agent configuring the vswitch can get very complex (especially
> when adding things like security groups, QoS policies, etc. etc.). We do
> not want to complicate Nova by having it perform all operations on the
> vswitch.
>
> Also, the Quantum agent may need to reconfigure the vswitch at any point,
> resulting from a change made to the quantum API (e.g., putting a quantum
> port in 'admin-down' state). Nova really only does anything network
> related when a VM is created, destroyed, or restarted. Thus, we have nova
> only do the absolute simplest networking step of creating the device
> presenting the vNIC, and informing the vswitch about it (and the
> corresponding tear-down).
>
> The OVS + Linux Bridge plugins have agents that you could use as a model.
>
> Dan
>
>
> On Tue, Jun 5, 2012 at 10:22 AM, Rami Cohen <ramic.home@gmail.com> wrote:
>
>> Irena,
>> In current Quantum/Nova Implementation and openvswitch plugin the VIF
>> driver performs the actual vif connectivity to the vswitch (using
>> 'ovs-vsctl'). This make sense since it reuse existing Nova messaging
>> mechanism and the fact that the Nova compute is already deployed on each
>> node (so why to deploy, maintain and communicate with additional agent?). I
>> would think that the best way is to enable quantum to pass parameters to
>> the VIF driver.
>> What do you think?
>>
>
>
>
>>
>> RamiC
>>
>> the Nova compute is already deployed on each host) the fact that the
>> parameters of quantum does not sent back to the driver
>>
>> On Tue, Jun 5, 2012 at 2:35 PM, Irena Berezovsky <irenab@mellanox.com>wrote:
>>
>>> Rami,****
>>>
>>> Following the recent discussions on the mailing list regarding the
>>> responsibility of the VIF driver, seems that it should be very thin and
>>> network provisioning should be handled by Quantum Plugin Agent as in
>>> OpenvSwitch and LinuxBridge plugins.****
>>>
>>> I have similar need to get attributes for the attached network/ port and
>>> seems that the way to do it is via API extension.****
>>>
>>> You can see the details in the following mailing thread: ****
>>>
>>> https://lists.launchpad.net/openstack/msg12716.html****
>>>
>>> ** **
>>>
>>> Hope this helps,****
>>>
>>> Irena****
>>>
>>> *From:* netstack-bounces+irenab=mellanox.com@lists.launchpad.net[mailto:
>>> netstack-bounces+irenab=mellanox.com@lists.launchpad.net] *On Behalf Of
>>> *Rami Cohen
>>> *Sent:* Tuesday, June 05, 2012 1:14 PM
>>> *To:* netstack@lists.launchpad.net
>>> *Subject:* [Netstack] Nova & Quantum integration****
>>>
>>> ** **
>>>
>>> Hi,
>>> Is there any mechanism to pass some parameters from Quantum Manager to
>>> the Quantum VIF driver (that is part of the Nova compute)?
>>> In particular, I saw that when Nova network calls Quantum API (create
>>> and attach ports) it ignores the return values sent from the quantum
>>> manager, so there is no formal way to reflect them back to the Nova compute.
>>>
>>> Thanks,
>>> RamiC
>>>
>>> ****
>>>
>>
>>
>>
>> --
>> RamiC™
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


--
RamiC™

Rami,Dan
Seems that this question may be relevant to nova guys. It's a question of design in first place. Is it correct to expose networking operation details to the nova-compute or it should be fully encapsulated inside nova-network?
Dan, how is it going to be managed in Folsom where QuantumManager will be dropped and nova parity will be achieved by using Quantum Client to call Quantum APIs?

Irena


From: Rami Cohen [mailto:ramic.home@gmail.com]
Sent: Tuesday, June 05, 2012 11:47 PM
To: Dan Wendlandt
Cc: Irena Berezovsky; netstack@lists.launchpad.net
Subject: Re: [Netstack] Nova & Quantum integration

Dan,
Thanks for your quick and detailed response.
While I understand that the agent is used for enhanced services while the driver is just for VM provisioning/destroying/restarting, I still think that reflecting the values returned by quantum API to the Quantum driver may be beneficial and it requires minimum effort (just returns the parameters by Nova network to the Nova compute. In particular, it may save a lot of (development and QA) effort when the agent is not needed.
What do you think?

RamiC

On Tue, Jun 5, 2012 at 9:30 PM, Dan Wendlandt <dan@nicira.com<mailto:dan@nicira.com>> wrote:
Rami,

A quantum agent configuring the vswitch can get very complex (especially when adding things like security groups, QoS policies, etc. etc.). We do not want to complicate Nova by having it perform all operations on the vswitch.

Also, the Quantum agent may need to reconfigure the vswitch at any point, resulting from a change made to the quantum API (e.g., putting a quantum port in 'admin-down' state). Nova really only does anything network related when a VM is created, destroyed, or restarted. Thus, we have nova only do the absolute simplest networking step of creating the device presenting the vNIC, and informing the vswitch about it (and the corresponding tear-down).

The OVS + Linux Bridge plugins have agents that you could use as a model.

Dan

On Tue, Jun 5, 2012 at 10:22 AM, Rami Cohen <ramic.home@gmail.com<mailto:ramic.home@gmail.com>> wrote:
Irena,
In current Quantum/Nova Implementation and openvswitch plugin the VIF driver performs the actual vif connectivity to the vswitch (using 'ovs-vsctl'). This make sense since it reuse existing Nova messaging mechanism and the fact that the Nova compute is already deployed on each node (so why to deploy, maintain and communicate with additional agent?). I would think that the best way is to enable quantum to pass parameters to the VIF driver.
What do you think?



RamiC

the Nova compute is already deployed on each host) the fact that the parameters of quantum does not sent back to the driver

On Tue, Jun 5, 2012 at 2:35 PM, Irena Berezovsky <irenab@mellanox.com<mailto:irenab@mellanox.com>> wrote:
Rami,
Following the recent discussions on the mailing list regarding the responsibility of the VIF driver, seems that it should be very thin and network provisioning should be handled by Quantum Plugin Agent as in OpenvSwitch and LinuxBridge plugins.
I have similar need to get attributes for the attached network/ port and seems that the way to do it is via API extension.
You can see the details in the following mailing thread:
https://lists.launchpad.net/openstack/msg12716.html

Hope this helps,
Irena
From: netstack-bounces+irenab=mellanox.com@lists.launchpad.net<mailto:mellanox.com@lists.launchpad.net> [mailto:netstack-bounces+irenab<mailto:netstack-bounces%2Birenab>=mellanox.com@lists.launchpad.net<mailto:mellanox.com@lists.launchpad.net>] On Behalf Of Rami Cohen
Sent: Tuesday, June 05, 2012 1:14 PM
To: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Subject: [Netstack] Nova & Quantum integration

Hi,
Is there any mechanism to pass some parameters from Quantum Manager to the Quantum VIF driver (that is part of the Nova compute)?
In particular, I saw that when Nova network calls Quantum API (create and attach ports) it ignores the return values sent from the quantum manager, so there is no formal way to reflect them back to the Nova compute.

Thanks,
RamiC


--
RamiC(tm)

--
Mailing list: https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack>
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack>
More help : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~




--
RamiC(tm)

On Tue, Jun 5, 2012 at 9:57 PM, Irena Berezovsky <irenab@mellanox.com>wrote:

> Rami,Dan****
>
> Seems that this question may be relevant to nova guys. It’s a question of
> design in first place. Is it correct to expose networking operation
> details to the nova-compute or it should be fully encapsulated inside
> nova-network?****
>
> Dan, how is it going to be managed in Folsom where QuantumManager will be
> dropped and nova parity will be achieved by using Quantum Client to call
> Quantum APIs?
>

Hi Irena,

Once our changes for Folsom are complete, nova-compute will leverage the
quantum client code to call Quantum APIs directly.

Dan



> ****
>
> ** **
>
> Irena****
>
> ** **
>
> ** **
>
> *From:* Rami Cohen [mailto:ramic.home@gmail.com]
> *Sent:* Tuesday, June 05, 2012 11:47 PM
> *To:* Dan Wendlandt
> *Cc:* Irena Berezovsky; netstack@lists.launchpad.net
> *Subject:* Re: [Netstack] Nova & Quantum integration****
>
> ** **
>
> Dan,
> Thanks for your quick and detailed response.
> While I understand that the agent is used for enhanced services while the
> driver is just for VM provisioning/destroying/restarting, I still think
> that reflecting the values returned by quantum API to the Quantum driver
> may be beneficial and it requires minimum effort (just returns the
> parameters by Nova network to the Nova compute. In particular, it may save
> a lot of (development and QA) effort when the agent is not needed.
> What do you think?
>
> RamiC
>
> ****
>
> On Tue, Jun 5, 2012 at 9:30 PM, Dan Wendlandt <dan@nicira.com> wrote:****
>
> Rami,****
>
> ** **
>
> A quantum agent configuring the vswitch can get very complex (especially
> when adding things like security groups, QoS policies, etc. etc.). We do
> not want to complicate Nova by having it perform all operations on the
> vswitch. ****
>
> ** **
>
> Also, the Quantum agent may need to reconfigure the vswitch at any point,
> resulting from a change made to the quantum API (e.g., putting a quantum
> port in 'admin-down' state). Nova really only does anything network
> related when a VM is created, destroyed, or restarted. Thus, we have nova
> only do the absolute simplest networking step of creating the device
> presenting the vNIC, and informing the vswitch about it (and the
> corresponding tear-down). ****
>
> ** **
>
> The OVS + Linux Bridge plugins have agents that you could use as a model.
> ****
>
> ** **
>
> Dan****
>
> ** **
>
> On Tue, Jun 5, 2012 at 10:22 AM, Rami Cohen <ramic.home@gmail.com> wrote:*
> ***
>
> Irena,
> In current Quantum/Nova Implementation and openvswitch plugin the VIF
> driver performs the actual vif connectivity to the vswitch (using
> 'ovs-vsctl'). This make sense since it reuse existing Nova messaging
> mechanism and the fact that the Nova compute is already deployed on each
> node (so why to deploy, maintain and communicate with additional agent?). I
> would think that the best way is to enable quantum to pass parameters to
> the VIF driver.
> What do you think?****
>
> ** **
>
> ****
>
>
> RamiC
>
> the Nova compute is already deployed on each host) the fact that the
> parameters of quantum does not sent back to the driver ****
>
> ** **
>
> On Tue, Jun 5, 2012 at 2:35 PM, Irena Berezovsky <irenab@mellanox.com>
> wrote:****
>
> Rami,****
>
> Following the recent discussions on the mailing list regarding the
> responsibility of the VIF driver, seems that it should be very thin and
> network provisioning should be handled by Quantum Plugin Agent as in
> OpenvSwitch and LinuxBridge plugins.****
>
> I have similar need to get attributes for the attached network/ port and
> seems that the way to do it is via API extension.****
>
> You can see the details in the following mailing thread: ****
>
> https://lists.launchpad.net/openstack/msg12716.html****
>
> ****
>
> Hope this helps,****
>
> Irena****
>
> *From:* netstack-bounces+irenab=mellanox.com@lists.launchpad.net [mailto:
> netstack-bounces+irenab=mellanox.com@lists.launchpad.net] *On Behalf Of *Rami
> Cohen
> *Sent:* Tuesday, June 05, 2012 1:14 PM
> *To:* netstack@lists.launchpad.net
> *Subject:* [Netstack] Nova & Quantum integration****
>
> ****
>
> Hi,
> Is there any mechanism to pass some parameters from Quantum Manager to the
> Quantum VIF driver (that is part of the Nova compute)?
> In particular, I saw that when Nova network calls Quantum API (create and
> attach ports) it ignores the return values sent from the quantum manager,
> so there is no formal way to reflect them back to the Nova compute.
>
> Thanks,
> RamiC****
>
>
>
> ****
>
> --
> RamiC™****
>
> ** **
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>
>
>
>
> --
> RamiC™****
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~