FS- Dedicate Public IP Addresses per tenant

Bug Reference

CLOUDSTACK-704

Branch

master, 4.2.0

Introduction

Current Scenario

Currently in CloudStack,

• A Public IP range can be dedicated to an account only during the creation of the range
• If an admin dedicates an IP range to an account then all the IPs of that range get acquired by a single isolated network in that account during dedication
• When a network that has a dedicated IP range is deleted, the mapping between the account that owned the network and the IP range persists
• Even if a range is dedicated to an account, any network that belongs to this account including the one that has acquired the IPs can acquire more IPs from the system pool
• An IP range that has been dedicated to an account cannot be released back to the system pool

Purpose

Modify the current CS behavior of Public IP dedication in Advanced zone to achieve the below requirements,

• Allow admins to dedicate a Public IP Address range to a tenant.
• Allow admins to release a Public IP Address range from a tenant

This document describes the specifications and design of this feature.

Glossary

1. System pool : The pool of Public IP addresses that belong to the system account

Feature Specifications

Feature is supported in Advanced zone only

Dedicating a Public IP range

• Admins should be allowed to dedicate a Public IP range to a specific account
• The range can be dedicated to an account either during the IP range creation or after it has been created
• In the following scenarios an admin request to dedicate an IP range should fail
  • IP range specified is non-existent
  • IP range specified has already been dedicated
  • If on dedication the account’s Public IP limits will be exceeded
  • Any one of the IPs in the range has already been acquired by a different account 

Creating a Public IP range

• During Public IP range creation, if admin specifies an account then the range should be dedicated to that account
  • But unlike the current CS behavior, all the IPs belonging to the range should not get acquired by a network in that account during dedication

Acquiring a Public IP

• If a user trying to acquire the IP belongs to an account that has a dedicated IP range then an IP from the dedicated range should be chosen
  • If all the IPs dedicated to the account have been acquired then the user can acquire IPs from the system pool
• If a user trying to acquire the IP belongs to an account that has no dedicated IP range then an IP from the system pool should be chosen 

Releasing a Public IP

• If a Public IP is dedicated to an account, then on release the IP should continue to be dedicated to the account

Releasing a dedicated Public IP range

• Admin should be allowed to release a Public IP range that is dedicated to an account back to the system pool
  • Even If one/more of the IPs belonging to the range is in use (load-balancing etc.), the IP range should be released back to the system pool
    •  The IPs that are in use should continue to be acquired by the account in which it is being used
  • If any of the IPs have been acquired but are not in use then the IPs should be disassociated and the entire range should be released back to the system pool (keeping with the current behavior)

Deleting a Public IP range

• No change from the existing CloudStack behavior
  • If one/more of the IPs belonging to the range is in use (load-balancing etc.), deletion will fail
  • If any of the IPs have been acquired but are not in use and if the range is dedicated then the IP will be disassociated and the range will be deleted

Network deletion

• If a network being deleted has acquired IPs from a dedicated IP range then even after the network deletion the IPs should continue to be dedicated to the account

Account deletion

• When an account is deleted, the IP ranges associated with the account should be released back to the system pool

Use cases

• Admins would like to reserve a fixed set of Public IP Addresses for a tenant.

Architecture and Design description

Web Services APIs

New API’s

Both the new APIs are available only for the ROOT admin

Existing API’s to be modified - None

UI flow changes

• In Infrastructure -> Zones -> <zone> -> <physical network> -> Public under ‘Ip Ranges’
  • If there are no accounts associated with the IP range show an Add button next to the range
    • If the button is clicked provide the same widget as the one for CreateVlanIpRanges that allows the admin to provide account name and domain
    • Action to perform – Call DedicatePublicIpRange API with id set to the id of the vlan ip range and account and domainId set to the values provided in the button
• In Infrastructure -> Zones -> <zone> -> <physical network> -> Public under ‘Ip Ranges’
  • Add an action to remove the account the IP range is dedicated to
  • Action to perform – Call ReleasePublicIpRange API with id set to the id of the vlan ip range

DB

No Database changes

Current DB configuration for dedicated Public IP range,

Table ‘account_vlan_map’ has an entry for every Public IP range that is dedicated to an account

Enhancement

1. Add a zone level configuration to configure if an account can acquire IPs from the system pool once the account has exhausted all of its dedicated Public IPs (default set to true).

Test cases

TBD

Usage

TBD