Page History

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 to achieve the below requirements,

...

This document describes the specifications and design of this feature.

Feature Specifications

Dedicating a Public IP range

...

• 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

• DedicateVlanIpRange API
  • Dedicate a VLAN IP range
  • Parameters – vlanid, account, domainid
• ReleaseVlanIpRange API
  • Release a VLAN IP range back to the system
  • Parameters - vlanid

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 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
• To avoid a potential starvation should there be a minimum (configurable limit) number of ranges that should always belong to the free pool?

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