Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

  • 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 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 IP's IPs can acquire more IP's IPs from the system pool
  • An IP range that has been dedicated to an account cannot be released back to the system pool

...

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

...

  • 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
    If admin tries to dedicate a
    • non-existent
    • IP range
    or an
    • specified has already been dedicated
    IP range then the request should fail
    • If
    by dedicating the IP address range,
    • on dedication the account’s Public IP limits
    are exceeded the request should fail
    • will be exceeded
    • Any one of the IPs in the range has already been acquired by a different account 

Creating a Public IP range

...

  • 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 IPs dedicated to the account have been acquired then the request should failuser 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 

...

  • Admin should be allowed to release a Public IP range that is dedicated to an account back to the system pool
    • Even If any one/more of the IP’s IPs belonging to the range are is in use (load-balancing etc.), the IP range should be released back to the system pool
      •  The IP's IPs that are in use should continue to be acquired by the account in which it is being used
    • If any of the IP’s IPs have been acquired but are not in use then the IP’s 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 in behavior, the IP range should 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

...

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

...

  • In Infrastructure -> Zones -> <zone> -> <physical network> -> Public under ‘Ip Ranges’
    • If there are no accounts associated with the Ip IP range show an Add button next to the range
      • If the button is clicked provide the same widget as the one for CreateVlanIp Ranges 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 vlanid id set to the id of the vlan ip range

DB

No DB Database changes

Current DB configuration for dedicated Public IP range,

In table Table ‘account_vlan_map’ will have 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 Public IP range is dedicated to

vlan_db_id

db id of the VLAN Public IP range

...

Enhancement

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

Test cases

TBD

Usage

...

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

A new global config use.system.public.ips

  • To allow root admin to disallow any account from acquiring public IPs from the system if the account has dedicated public IPs and these dedicated public IPs have all been consumed. 
  • Will be configurable at the account level too.
  • Default value is true.

Usage

Dedication by admin is equivalent to users acquiring IP and hence user should be charged from the time an IP is dedicated

  • When an IP is dedicated usage event 'EVENT_NET_IP_ASSIGN' should be published 
  • If an IP is dedicated event 'EVENT_NET_IP_ASSIGN' should not be published when the dedicated IP is acquired
  • When a dedicated IP is released from an account event 'EVENT_NET_IP_RELEASE' should be published only when the the range of IPs it belongs to is released back to the system pool and not when an account that has acquired the IP releases it