| 2013-02-10 13:00:57 |
Salvatore Orlando |
bug |
|
|
added bug |
| 2013-02-10 13:01:07 |
Salvatore Orlando |
tags |
|
api nicira |
|
| 2013-02-10 13:01:27 |
Salvatore Orlando |
description |
As of the current implementation, the Nicira plugin always adds a default SNAT rule before creating the floating IPs.
This means that we are unable to clearly separate the 'floating IP (DNAT)' and 'external gateway access (SNAT)' offered by the Quantum logical router.
- One can configure a router for SNAT, but not do DNAT (just doing PUT /routers/<router-id> {'external_network_info: {'network_id': <ext_net>id> }} )
- However one cannot decide to allow a router to connect floating IPs without doing SNAT.
To this aim the 'external_network_info' data structure can be extend by adding explicit attributes which state what operations are possible on such external network.
For instance:
{'external_network_info':
{
'network_id': <net_id>,
'snat': false,
'dnat': true
}
Recent work on dict validation might be used to easily ensure the sanity of the data passed to the Quantum API.
This is probably a more generic issue in the Quantum model, we're keeping it specific for the Nicira plugin at the moment as the use case, and the proposed API change need to be discussed with the community first. |
As of the current implementation, the Nicira plugin always adds a default SNAT rule before creating the floating IPs.
This means that we are unable to clearly separate the 'floating IP (DNAT)' and 'external gateway access (SNAT)' offered by the Quantum logical router.
- One can configure a router for SNAT, but not do DNAT (just doing PUT /routers/<router-id> {'external_network_info: {'network_id': <ext_net>id> }} )
- However one cannot decide to allow a router to connect floating IPs without doing SNAT.
To this aim the 'external_network_info' data structure can be extend by adding explicit attributes which state what operations are possible on such external network.
For instance:
{
'external_network_info':
{
'network_id': <net_id>,
'snat': false,
'dnat': true
}
}
Recent work on dict validation might be used to easily ensure the sanity of the data passed to the Quantum API.
This is probably a more generic issue in the Quantum model, we're keeping it specific for the Nicira plugin at the moment as the use case, and the proposed API change need to be discussed with the community first. |
|
| 2013-02-19 16:29:01 |
Salvatore Orlando |
quantum: milestone |
grizzly-3 |
grizzly-rc1 |
|
| 2013-02-25 18:00:56 |
Salvatore Orlando |
quantum: milestone |
grizzly-rc1 |
havana-1 |
|
| 2013-03-11 00:54:12 |
Salvatore Orlando |
summary |
Allow the NVP plugin to use floating IPs without SNAT |
Allow the NVP plugin to use configurable gateway modes. |
|
| 2013-03-11 00:54:31 |
Salvatore Orlando |
summary |
Allow the NVP plugin to use configurable gateway modes. |
Allow the NVP plugin to use configurable gateway modes |
|
| 2013-03-11 00:55:33 |
Salvatore Orlando |
description |
As of the current implementation, the Nicira plugin always adds a default SNAT rule before creating the floating IPs.
This means that we are unable to clearly separate the 'floating IP (DNAT)' and 'external gateway access (SNAT)' offered by the Quantum logical router.
- One can configure a router for SNAT, but not do DNAT (just doing PUT /routers/<router-id> {'external_network_info: {'network_id': <ext_net>id> }} )
- However one cannot decide to allow a router to connect floating IPs without doing SNAT.
To this aim the 'external_network_info' data structure can be extend by adding explicit attributes which state what operations are possible on such external network.
For instance:
{
'external_network_info':
{
'network_id': <net_id>,
'snat': false,
'dnat': true
}
}
Recent work on dict validation might be used to easily ensure the sanity of the data passed to the Quantum API.
This is probably a more generic issue in the Quantum model, we're keeping it specific for the Nicira plugin at the moment as the use case, and the proposed API change need to be discussed with the community first. |
As of the current implementation, the Nicira plugin always adds a default SNAT rule before creating the floating IPs.
This means that we are unable to clearly separate the 'floating IP (DNAT)' and 'external gateway access (SNAT)' offered by the Quantum logical router.
- One can configure a router for SNAT, but not do DNAT (just doing PUT /routers/<router-id> {'external_network_info: {'network_id': <ext_net>id> }} )
- However one cannot decide to allow a router to connect floating IPs without doing SNAT.
To this aim the 'external_network_info' data structure can be extended by adding explicit attributes which state what operations are possible on such external network.
For instance:
{
'external_network_info':
{
'network_id': <net_id>,
'snat': false,
'dnat': true
}
}
The blueprint l3-ext-gw-modes adds this kind of support in the API layer and the OVS plugin. The NVP plugin might benefit from this feature too. |
|
| 2013-03-29 14:04:31 |
Mark McClain |
quantum: importance |
Medium |
Wishlist |
|
| 2013-03-29 14:04:34 |
Mark McClain |
quantum: status |
New |
Triaged |
|
| 2013-04-04 10:38:43 |
OpenStack Infra |
quantum: status |
Triaged |
In Progress |
|
| 2013-05-29 08:36:21 |
Mark McClain |
quantum: milestone |
havana-1 |
havana-2 |
|
| 2013-07-17 01:51:05 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Committed |
|
| 2013-07-17 12:01:46 |
Thierry Carrez |
neutron: status |
Fix Committed |
Fix Released |
|
| 2013-10-17 11:45:59 |
Thierry Carrez |
neutron: milestone |
havana-2 |
2013.2 |
|
