Andy Kurth created VCL-960:
------------------------------
Summary: Rework fixed IP address functionality
Key: VCL-960
URL: https://issues.apache.org/jira/browse/VCL-960
Project: VCL
Issue Type: Improvement
Components: database, vcld (backend)
Reporter: Andy Kurth
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:
{code}
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");
}
{code}
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
