https://blueprints.launchpad.net/blazar/+spec/floatingip-reservation
This network plugin supports floating IP reservation.
The Neutron service creates and associates floating IPs to projects in a first come first serve style. The order sometimes causes lack of floating IPs in a cloud, especially in a private cloud, since the cloud provider has a limited number of floating IPs available for their cloud.
Blazar enables users to reserve floating IPs by specifying the external network ID of floating IPs the users want to reserve. Users can treat the reserved floating IP as usual, except for the create floating IP operation.
A basic idea for the floating IP reservation and its scenario are as follows:
Blazar regards IP addresses out of Neutron’s allocation_pools parameter as reservable resources. The allocation_pools is just a range of IP addresses from which Neutron automatically creates floating IPs. When an admin creates a floating IP with a specific IP address which is out of the range, Neutron accepts the request and the new floating IP has the requested IP address. It enables Blazar to manage creation of the reserved floating IPs by itself.
Blazar adds two tags, “blazar” and “reservation:<reservation-id>” to the reserved floating IP to make it easy for users to query their reserved floating IPs.
To realize the scenario, this blueprint introduces a new resource plugin, named “virtual:floatingip” for Blazar.
Blazar maps the reserved floating IPs to a dedicated external network. The external network is hidden from the regular users by neutron’s policy.json. Blazar creates the reserving user’s external network at lease start time and deletes the network at lease end time on behalf of the user.
The advantage of this approach is the reserved resource is separated from user’s non-reserved resources. It’s easy for Blazar to handle the reserved resources at start date and end date.
The disadvantage is that this approach needs the same amount of physical networks/configuration as the number of reserved networks. For example, if a cloud admin sets up their external network as type_driver is flat and mechanical_driver is ovs, Neutron needs as many OVS bridges as the number of reserved external networks.
Blazar attaches the reserved floating IPs to a specific port while the floating IP reservation is active. When the reservable floating IP is not in use, the IP belongs to Blazar’s service tenant. It prevents users from creating floating IPs using the reservable IPs.
The advantage is that Blazar can handle the creation and deletion of floating IP and the reservable floating IPs belongs to the range of the allocation_pools parameter.
The drawback is that users need to use a new workflow to manage the reserved floating IP. Without Blazar, users can associate and de-associate a floating IP to/from a port. But Blazar does in this approach instead of users. It requires users to have two workflows for managing floating IPs.
This plugin introduces four new tables, “floatingip_reservations”, “required_floatingips”, “floatingip_allocations” and “floatingips”.
The “floatingip_reservations” table keeps user request information for their floating IP reservations. The role of this table is similar to the role of the computehost_reservations table in the host reservation plugin. This table has id, network_id and amount columns. The table has a relationship with the set of floating IPs requested by user.
The “required_floatingips” table represents floating IPs that a user requests for a reservation.
The “floatingip_allocations” table has the relationship between the floatingip_reservations table and the floatingips table.
The “floatingips” table stores information of floating IPs themselves. The reservable floating IPs are registered in the table. The floating_ip_address column has unique constraints because the id column is generated by Blazar. Neutron generates floating ip’s id during floating ip creation.
The table definitions are as follows:
CREATE TABLE floatingip_reservations (
id VARCHAR(36) NOT NULL,
reservation_id VARCHAR(255) NOT NULL,
network_id VARCHAR(255) NOT NULL,
amount INT UNSIGNED NOT NULL,
PRIMARY key (id),
INDEX (id, reservation_id)
FOREIGN KEY (reservation_id)
REFERENCES reservations(id)
ON DELETE CASCADE,
);
CREATE TABLE required_floatingips (
id VARCHAR(36) NOT NULL,
floatingip_reservation_id VARCHAR(36) NOT NULL,
address VARCHAR(255) NOT NULL,
PRIMARY key (id),
FOREIGN KEY (floatingip_reservation_id)
REFERENCES floatingip_reservations(id)
ON DELETE CASCADE,
);
CREATE TABLE floatingip_allocations (
id VARCHAR(36) NOT NULL,
reservation_id VARCHAR(255) NOT NULL,
floatingip_id VARCHAR(255) NOT NULL,
);
CREATE TABLE floatingips (
id VARCHAR(36) NOT NULL,
floating_network_id VARCHAR(255) NOT NULL,
subnet_id VARCHAR(255) NOT NULL,
floating_ip_address VARCHAR(255) NOT NULL,
reservable BOOLEAN NOT NULL,
UNIQUE (subnet_id, floating_ip_address)
);
The floating IP reservation introduces a new resource_type to the lease APIs and four new admin APIs to manages floating IPs.
Request Example:
{
"name": "floatingip-reservation-1",
"reservations": [
{
"resource_type": "virtual:floatingip",
"network_id": "external-network-id",
"required_floatingips": [
"172.24.4.10",
"172.24.4.11"
],
"amount": 3
}
],
"start_date": "2017-05-17 09:07",
"end_date": "2017-05-17 09:10",
"events": []
}
Response Example:
{
"lease": {
"name": "floatingip-reservation-1",
"reservations": [
{
"id": "reservation-id",
"status": "pending",
"lease_id": "lease-id-1",
"resource_id": "resource_id",
"resource_type": "virtual:floatingip",
"network_id": "external-network-id",
"required_floatingips": [
"172.24.4.10",
"172.24.4.11"
],
"allocated_floatingips": [
"172.24.4.10",
"172.24.4.11",
"172.24.4.100"
],
"amount": 3,
"created_at": "2017-05-01 10:00:00",
"updated_at": "2017-05-01 11:00:00",
}],
"start_date": "2017-05-17 09:07",
"end_date": "2017-05-17 09:07",
..snip..
}
}
The four new APIs are admin APIs by default.
Request Example:
{
"floating_network_id": "external-network-id",
"floating_ip_address": "floating_ip_address"
}
Response Example:
{
"floatingip": {
"id": "floating-ip-id",
"floating_network_id": "external-network-id",
"floating_ip_address": "floating_ip_address",
"subnet_id": "subnet-id",
"reservable": true,
"created_at": "2020-01-01 10:00:00",
"updated_at": null
}
}
Response Example:
{
"floatingips": [
{
"id": "floating-ip-id",
"floating_network_id": "external-network-id",
"floating_ip_address": "floating_ip_address",
"subnet_id": "subnet-id",
"reservable": true,
"created_at": "2020-01-01 10:00:00",
"updated_at": null
}
]
}
Response Example:
{
"floatingip": {
"id": "floating-ip-id",
"floating_network_id": "external-network-id",
"floating_ip_address": "floating_ip_address",
"subnet_id": "subnet-id",
"reservable": true,
"created_at": "2020-01-01 10:00:00",
"updated_at": null
}
}
No Request body and Response body.
The floating IP API doesn’t have an update API because all of the information is retrieved from Neutron API.
None
None
An user can reserve floating IPs as well as host or instance reservation in one lease.
python-blazarclient will support the floating IP reservation.
None
None
This is a first implementation for networking resources.
Some configurations for Neutron util class will be introduced to blazar.conf. If the cloud admin want to activate the network reservation, they needs to setup the configuration.
None
API tests and scenario tests need to be implemented.
This BP adds new APIs and resource type to the lease APIs. The API reference and the Blazar documentation need to be updated.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.