Talk:L3-ext-gw-modes-spec
Revision as of 22:48, 27 March 2013 by Salvatore-orlando (talk | contribs) (Created page with "''nati-ueno'': There is usecase we need SNAT or DNAT on the others port. How about keep external_network_info with current form and add, dnat_ports= [ port_id1,port_id2.....")
nati-ueno:
There is usecase we need SNAT or DNAT on the others port. How about keep external_network_info with current form and add,
dnat_ports= [
port_id1,port_id2...
] snat_ports= [
port_id1,port_id2...
]
salvatore-orlando:
This is a valid argument - and also a very reasonable use case - , but I am not sure whether it would be the right API approach or not.
- The external_network_info attribute was conceived as a dict rather than a single attribute for the purpose of allowing user to specify more properties - enabling and disabling snat are just an example of such properties.
- The declaration of lists of ports on which one wants to do snat/dnat implies a concept of router port, that we unfortunately lack. The blueprint https://blueprints.launchpad.net/quantum/+spec/l3-router-port-relationship proposes to add such concept. Once we have this concept, enable_snat and enable_dnat might become attributes of the router port, which is probably easier than handling uuids. NOTE: The code for that blueprint is now abandoned, but Mark said he will restore it.
- List attributes are always a bit tricky for API users (when you do a PUT you replace the whole list, so you need to do a GET first). I'm not saying we should not have them, but if we have an easy alternative, there's probably a point to choose the alternative.
- On a slightly unrelated note, when we do apply NAT to interface different from the gateway, does it make sense binding it to ports? Or is the concept more similar to the 'extraroute' extension? In that case you would have a list of SNAT/DNAT rules which apply to the router as a whole.
