You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 19
Next »
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 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.
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 IP’s 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 any of the IP’s belonging to the range is in use (load-balancing etc.), the IP range should be released back to the system pool
- The IP's that are in use should continue to be acquired by the account in which it is being used
- If any of the IP’s have been acquired but are not in use then the IP’s 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 in behavior, the IP range should 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
ApiName |
Request parameters |
Response parameters |
dedicatePublicIpRange |
- id (id of the Public IP range, type - uuid, required - true)
- account (account the Public IP range will be dedicated to, type - String, required - true)
- domainid (domain ID of the account the Public IP range is dedicated to, type - uuid, required - true)
|
VlanIpRangeResponse |
releasePublicIpRange |
- id (id of the Public IP range, type - uuid, required - true)
|
Boolean |
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
Parameter name |
description |
id |
primary key |
account_db_id |
account the IP range is dedicated to |
vlan_db_id |
db id of the IP range |
Enhancement
- Add a zone level configuration to configure if a tenant can acquire IP's from the system pool once the tenant has exhausted all Public IP's dedicated to it with default value set to true
Test cases
TBD
Usage
TBD