[RFE][floatingip port_forwarding] Add port ranges
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Wishlist
|
Pedro Henrique Pereira Martins |
Bug Description
Problem Description
=================
Currently, if a user wants to create NAT rules that cover multiple ports, he/she needs to create them one by one, which is cumbersome in some use cases. Having said that, we suggest changing the Floating IP port forwarding API to allow the use of port ranges to create NAT rules. The changes are presented as follows
Proposed Change
===============
### API JSON
We propose to extend the current floating IP port forwarding API to handle a range of ports instead of a one-to-one mapping. We have different alternatives to implement such a feature. We can change the JSON the API receives, adding new attributes, such as `internal_
For example:
Current JSON :
{
"port_
"protocol": "tcp",
"internal_
"internal_
"internal_
"external_
"description": "desc"
}
}
Adding new attributes :
{
"port_
"protocol": "tcp",
"internal_
"internal_
"internal_
"internal_
"external_
"external_
"description": "desc"
}
}
Or, the alternative, changing the content of the attributes:
{
"port_
"protocol": "tcp",
"internal_
"internal_
"internal_
"external_
"description": "desc"
}
}
We believe that the last JSON format is the best one; because it generates fewer changes in the API usage and is simple for the user to understand and use. Therefore, these are the changes we are proposing to be implemented.
### Database persistence
Besides the JSON (rest API), we will need to change the way that the application persists the port forwarding rules in the database. We have two different alternatives to change the database schema.
Using the current database schema sample:
+------
| id_____
+------
| floatingip_
+------
| external_
+------
| internal_
+------
| protocol_
+------
| socket_
+------
The above DB dump shows the scenario of a user creating a floatingip port forwarding rules with the port ranges 80-81 mapping into a VM ports range 8080-8081. Using this method, we will delegate all the responsibility of maintaining the ranges to the application level since the ports range is not specified in the DB schema.
On a different approach, we can work using an extended database schema:
+------
| id_____
+------
| floatingip_
+------
| external_
+------
| internal_
+------
| protocol_
+------
| internal_
+------
| internal_
+------
Using the above proposal, we will reduce the number of entries in the database to represent a port range; therefore, we will remove from the application level the responsibility to find and join all the sequential ports in a floatingip id rule. However, the application has to handle ports collision.
We think that the last alternative for the DB schema changes suits better the context we have in Neutron, because we can easily see an entry in the DB table and identify the ports that this rule uses.
### Validations
Here follows a summary of all of the validation executed by the system:
- Only N(external port[s]) to N (internal port[s]) are allowed or N(external port[s]) to 1 (internal port). Therefore, all of the other combinations (1-N, N-M, M-N) are not allowed and will generate an error
- When defining a port(s) range, the ports in this range cannot be already in use by any other port forwarding rule for the same floating IP and protocol
- A valid port is a number between 1 and 65535. All other cases will generate an error. Even though “0” is a valid port, we will not allow its use as it is reserved.
- The notation to define a port range is the following: <port_range_
This is the change we are proposing to be implemented.
Changed in neutron: | |
assignee: | nobody → Pedro Henrique Pereira Martins (pedrohpmartins) |
Changed in neutron: | |
importance: | Undecided → Wishlist |
Changed in neutron: | |
status: | In Progress → Fix Released |
Hi,
I would like to discuss it on next Neutron drivers meeting which will be on Friday: http:// eavesdrop. openstack. org/#Neutron_ drivers_ Meeting - so it would be great if You could join there if there would be any additional questions. But RFE should be discussed even if You will not be able to attend this meeting.