Floating IP Reservation

https://blueprints.launchpad.net/blazar/+spec/floatingip-reservation

This network plugin supports floating IP reservation.

Problem description

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.

Use Cases

  • A user plans to scale up a service during a specific time window and the service requires a new floating IP for global access.

  • A user plans to start a new service and wants to make sure a floating IP is available at the start time.

  • A cloud admin does not have enough floating IPs to give to all users

    • The admin wants to give a user a floating IP with either the host or instance reservation.

Proposed change

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:

  1. The admin registers some floating IPs used for floating IP reservation with Blazar. The admin calls Blazar’s floating IP API with a request body which includes public network ID and its floating IP address. The floating IP address must be out of allocation_pools in the external network subnets.

  2. A user calls the create lease API with external network ID, start date, and end date. Blazar checks availability of a floating IP for the request. If a floating IP is available, Blazar creates an allocation between the floating IP and the reservation, then returns the reservation ID. If not, Blazar doesn’t return a reservation ID.

  3. At the start time, Blazar creates the reserved floating IP in the user’s tenant (project). Then the user can attach, detach, and delete the floating IP as usual.

  4. At the end time, Blazar removes the reserved floating IP from the user’s tenant, if the user hasn’t deleted the floating IP already.

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.

Alternatives

Dedicated External Network approach

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.

Associated Port approach

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.

Data model impact

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)
);

REST API impact

The floating IP reservation introduces a new resource_type to the lease APIs and four new admin APIs to manages floating IPs.

Changes in the lease APIs

  • URL: POST /v1/leases

    • Introduced new resource_type, virtual:floatingip, for a reservation.

    • The network_id is an external network ID from which the user wants to reserve a floating ip.

    • The required_floatingips is an optional key. The key represents a list of floating IPs which must be included in the reservation. In the request sample, an user wants 3 floating IPs, and wants to spcifiy 2 of 3 floating IPs and doesn’t care of 1 of 3 floating IP.

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..
  }
}

  • URL: GET /v1/leases

  • URL: GET /v1/leases/{lease-id}

  • URL: PUT /v1/leases/{lease-id}

  • URL: DELETE /v1/leases/{lease-id}

    • The change is the same as POST /v1/leases

New floating IP APIs

The four new APIs are admin APIs by default.

  • URL: POST /v1/floatingips

    • The floating_network_id is an external network ID the admin adds as Blazar’s resource.

    • The floating_ip_address is a specific floating IP address the admin wants to add. The IP address must be the out of allocation_pools. When admin calls the API, Blazar fetches the subnet info from Neutron and verifies the floating IP is out of allocation_pools and within its CIDR network.

    • The floating_ip_address can’t be an optional parameter since IPs outside of the allocation_pool is commonly used by network equipment, a router, a loadbalancer and etc.

Request Example:

{
  "floating_network_id": "external-network-id",
  "floating_ip_address": "floating_ip_address"
}

  • The reservable key is a flag describing if the floating IP is reservable or not. The flag is always True until the floating IP plugin supports the resource healing feature. (Supporting resource healing to floating IP is out of scope in this spec)

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
  }
}

  • URL: GET /v1/floatingips

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
      }
  ]
}

  • URL: GET /v1/floatingips/{floatingip-id}

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
  }
}

  • URL: DELETE /v1/floatingips/{floatingip-id}

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.

Security impact

None

Notifications impact

None

Other end user impact

An user can reserve floating IPs as well as host or instance reservation in one lease.

python-blazarclient will support the floating IP reservation.

Performance Impact

None

Other deployer impact

None

Developer impact

This is a first implementation for networking resources.

Upgrade impact

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.

Implementation

Assignee(s)

Primary assignee:

muroi-masahito

Other contributors:

None

Work Items

  • Create Neutron API utility class

  • Create the new DB tables

  • Create the floating IP reservation plugin

  • Create the floating IP API object and its route in blazar.api.v1

  • Add floating IP reservation supports in python-blazarclient

  • Add scenario tests and API tests in blazar-tempest-plugin

  • Update Blazar docs, API reference and user guide

Dependencies

None

Testing

API tests and scenario tests need to be implemented.

Documentation Impact

This BP adds new APIs and resource type to the lease APIs. The API reference and the Blazar documentation need to be updated.

References

  1. Draft for floating IP reservation: https://etherpad.openstack.org/p/network-resource-reservation

  2. Denver PTG discussion: https://etherpad.openstack.org/p/blazar-ptg-stein

History

Revisions

Release Name

Description

Stein

Introduced