[VCL-960] Rework fixed IP address functionality

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: database, vcld (backend)
• Assignee: Unassigned
• Reporter: Andrew Kurth
• Created: 06/Jul/16 15:02
• Updated: 06/Jul/16 15:02

Description

The way the fixed IP code was implemented could be greatly improved.

Currently, rows are added and removed from the variable table for each server request with a fixed IP. This is bad for a few reasons:

The variable table shouldn't be used as a lazy way to store dynamic reservation information. It was intended to store more general pieces of information where it doesn't make sense to use a dedicated table or a dedicated column in another table. Configuration parameters should go in the variable table, not major reservation parameters.

There is no solid relationship between a request/reservation in the database and a fixed IP entry stored in the variable table. If you wanted to construct a query for reservations and join into that query a fixed IP value which may or may not exist, you'd have to dynamically construct a query to forms the fixedIPsr<server request ID> name of the variable. This is rubbish.

Fixed IP's are only possible on a 1 per server request basis because of the name chosen for the variable names. What if you wanted to make a cluster request of a few computers, each of which having its own fixed IP?

Cleanup. For other reservation details such as natport and computerloadlog, the entries in corresponding tables automatically get deleted when a reservation/request is deleted. This is impossible to implement within the database using the variable table. The code is supposed to clean out variable entries but I have seen where it failed to do so. Simply finding orphaned entries in the variable table is somewhat of a chore due to the free-form variable name.

Code style. The backend code related to fixed IP's isn't clean and organized. For example, there's a perfectly good delete_variable subroutine in utils.pm but in reclaim.pm there's code which constructs an SQL query:

my $delete_sql_statement = "DELETE variable FROM variable WHERE name = '$variable_name' ";
if (database_execute($delete_sql_statement)) {
notify($ERRORS{'DEBUG'}, 0, "Deleted server reservation entry for $variable_name from variable table");
}

Note: the lack of indentation on the notify line was omitted intentionally because that's how it looks in the actual code.

On the topic of server requests, we need to get rid of this concept entirely. It was a poor design from the start and never properly discussed before being implemented. A request is a request. A request may be for a cluster where there are multiple reservations tied to it. You can add additional features such as group access, fixed IP addresses, and in the future, special storage or network configurations to each reservation. You may want to have your request show up with a customized name on your reservations page. I'd like to be able to do this for any request, not just the ones I happened to select the "Server Request" checkbox when I created them. Any request may or may not have an indefinite end time. Tying these features only to server requests is severely limiting.

How to improve things? Here are a few considerations:

All IP information should be stored in dedicated tables and columns. This will make it easy to query a request/reservation and determine if any special IP address parameters exist.

We need to be able to store a list or ranges of IP addresses which can be used.

Available IP addresses will vary depending on where the reservation resides or which management node it is assigned to. There must be a way to associate/map available IP addresses to a management node.

It's possible that multiple management nodes reside in a single location and use the same IP space. Therefore, mapping of available IP's to management nodes isn't 1:1. It should be flexible so that you can say "these X management nodes can all handle these IP's".

A dedicated IP doesn't necessarily mean it replaces the normal public IP address assigned to the computer. A reservation should be able to receive it's regular public IP and an additional dedicated IP on a different VLAN or interface.

You may need multiple dedicated IP's for a single reservation on different VLANs or interfaces.

There needs to be a way for the backend to determine which interface, VM network, etc. to use when configuring a dedicated IP.

You should be able to select dedicated IP address for any reservation, not just server requests.

Administrators must be able to control who can select a dedicated IP address and which IP's they have access to.

I'm thinking the most logical way to implement this would be to define a single IP address as a new resource type. Add a new IPaddress resource group type. These groups would be mapped to management node groups. Privileges for IPaddress resource groups would be handled the same as for computers and images in the privilege tree.

Add a subnet table to the database. This would include the subnet IP, mask, gateway, NTP servers, etc:

id	network	netmask	gateway	dnsservers	ntpservers

We also need to consider how VLANs could be implemented. For example, I want to regular reservation with the normal private and public IPs, but need an extra address bound on a certain VLAN. The VLAN number could potentially go in the subnet table.

Add an IPaddress table to the database. This would include:

id	subnetid	address

resource.subid would correlate to IPaddress.id.

Add a reservationIPaddress mapping table:

reservationid	IPaddressid

The front end would handle adding and modifying the IP's and ensuring that the IP's are valid for the subnet. The subnet table will be useful for making it easy to validate things.