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 IP's 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 IP's can acquire more IP's from the free 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.

Feature Specifications

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
• If admin tries to dedicate a non-existent IP range or an already dedicated IP range then the request should fail
• If by dedicating the IP address range, the account’s Public IP limits are exceeded the request should fail

Creating a Public VLAN IP range

• During VLAN 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 IP’s dedicated to the account have been acquired then the request should fail
• 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
  • If any of the IP’s belonging to the range are in use (load-balancing etc.) the release should fail
  • If any of the IP’s have been acquired but are not in use then the IP’s should be disassociated and released back to the free pool (keeping with the current behavior)

Deleting a Public VLAN IP range

• No change in behavior, the IP range should be deleted

Network deletion

• If a network being deleted has acquired IPs from a dedicated IP range then 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 also be deleted

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

Existing API’s to be modified

• None

UI flow changes

• 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 ReleaseVlanIpRange API with vlanid set to the id of the vlan ip range

DB

No DB changes

Current DB configuration for dedicated Public IP range

• In table ‘user_ip_address’ the fields account_id and domain_id will be set to the account the IP address is dedicated to
• In table ‘account_vlan_map’ there will be a VLAN entry if a VLAN Public IP range is dedicated to an account

Open Issues

• To avoid a potential starvation should there be a minimum (configurable limit) number of ranges that should always belong to the free pool?

Test cases

TBD

Usage

TBD